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!
Well, I think this is going to be my first post in English in this blog (I gently ask to my English readers to forgive me this daring :-D ). A few days ago I submitted a simple and innocent tweet that generated a conversation with Ken Gonzalez ,and finally derived to this blog post. Everything started as you can see in the image:
When I explain the PDCA cycle both in ITIL® and (more intensively) in ISO/IEC 20000 training (Foundations Level and in the specially focused class called Process Management and Improvement according to ISO/IEC 20000 ) we start reading the chapter 4 of the standard, called “Planning and Implementing Service Management”. In this chapter, the standard describes a giant PDCA cycle needed to carry on the “project” of implementing the Management System, so we have 4 sub-chapters that describes the detailed requirements of the standard in order to build and run the SMS (Service Management System).
Students see a very nice graphic that explain the different PDCA steps and different inputs and outputs needed for the process. I explain them the requirements using a whiteboard where I draw a circle and move my hands following the line while I explain… the result is quite similar to what you can see in our first animation
As you can see in the animation, the IT organization is like a planet doing a complete set of orbits around the center of the Solar System (Service Management Quality in this example?) but this approach is too simple to try to represent the reality. Demming didn’t invent the PDCA cycle for such a big and complex change like putting in place a Management System for IT Service Management, a “project” that can last at least one complete year (just like a complete cycle around the Solar System!); he invented it for micro-changes, and in fact when you use it or when you imagine how an organization will manage to guide and continuously improve the Management System you can not imagine a BIG PLAN with a BIG DO followed by a GIANT CHECK with a MONSTER ACT
Well… some companies do; they imagine a BIG PLAN and then they sign for the BIG PROJECT and then there appear the Big Hordes of black_suite_with_white_shirt_and_dark_ties called “the consultant team”… they work hard for about 60 days and then the go out of the room with… THE PLAN, a book thicker than a Holy Bible plenty of drawings, RACI matrixes and workflows… but in fact this does not work, and times times of multi-million bucks contracts are finished.
So let’s imagine that we are doing things like people who has a little of common sense and then we will discover that we have a lot of small PDCA cycles that are collaborating together to build that first image of a big PDCA.. different teams, different knowledge areas, different practices but a single project in mind. Then we can imagine this as the second derivative of the first image: now, we are not in the Earth doing an orbit around the Sun, but we are in the Moon (as always! :-D) orbiting around Earth, building small PDCA cycles; you can visualize this situation in our second animation:
But you don’t need to stop in the second derivative… you can imagine a very small PDCA cycle for each small initiative and then one more time a small PDCA for each activity until you reach your level of micro-change. If you draw this infinite (well… it MUST be finite if you want to finish your cycle some day before Doom’s Day!) you will see the Fractal Nature of the PDCA cycle, and once you have seen this light, you will never see the cycle as a simple circle never again.
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:
[…]
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.
Ayer me cayó en las manos, gracias a la amabilidad de Luis Morán (uno de los miembros del equipo de autores) el libro titulado ISO/IEC 20000 Guía completa de aplicación para la gestión de los servicios de tecnologías de la información.
Como se pueden imaginar, en menos de 24 horas ha sido imposible que haya leído un libro de 775 páginas en tamaño cuartilla, pero la curiosidad ha sido lo suficientemente fuerte como para que apartase temporalmente la lectura que tengo en curso y me llevara la nueva adquisición de paseo en el metro. La primera impresión es que es un libro enfocado a aclarar todos los conceptos alrededor de la gestión de servicios según dicta la norma, con un índice prácticamente paralelo al de la ISO y con todos los contenidos necesarios para comprender en detalle no sólo la parte de requerimientos (ISO/IEC 20000-1) sino que también toda la parte de guía de recomendaciones (ISO/IEC 20000-2).
Del libro me han gustado varios detalles. El primero, es que no sólo se habla de la norma, sino que se enriquece todo el mensaje con continuas alusiones a otros estándares que conviven con la ISO 20.000 en el mundo del Gobierno y la Gestión de Servicios: hay referencias a COBIT, a CMMI y a SPICE, por ejemplo.
Lo segundo es que no es un libro integrista:está publicado por AENOR y está centrado en la norma, pero es lo suficientemente crítico como para hacernos notar (de una forma políticamente correcta) las carencias que tiene el estándar y nos hace reflexionar al respecto. Un ejemplo claro de esto es la carencia clara que tiene la norma ISO/IEC 20.000 en el sentido de que no contiene una definición del término servicio.(carencia que ya habíamos hecho notar en este blog en el artículo de 2007 titulado La Importancia de las Palabras) Pues bien, el comentario al respecto de los autores dice lo siguiente:
El término servicio ya se da por sentado en estas normas y por lo tanto no se define en ellas, pero para las áreas TI internas de las empresas no les es fácil encajarlo en su actividad. […]
El tercer detalle importante que destila el libro es la experiencia. No se queda en un trabajo teórico de análisis de la norma, sino que aporta ejemplos y orientación que se nota que viene del mundo real, no del mundo teórico.
En cuarto lugar, me han encantado algunos “guiños” que he visto dirigidos a la comunidad más freak del mundo de la Gestión de Servicios. Un ejemplo rápido son las figuras 4.2 y 4.4 del libro… :-) [lo habrán hecho los autores pensando en hacer un guiño a la comunidad freak? o lo habrán hecho inconscientemente y yo soy un freak impresionante?]
Ojalá que los chicos de AENOR junto con el equipo de autores se animen y den el paso de traducirlo al inglés, porque sería una gran contribución al sector a nivel internacional.
En definitiva, un libro muy recomendable, especialmente para tres tipos de colectivos:
Finalmente, para que no todo sean flores y no vayan a pensar que los autores me han pagado más de una cerveza, quisiera remarcar sólo dos cosillas que le he echado de menos:
Puedes descargarte las primeras 63 páginas del libro gratuitamente desde la web del itSMF España y los autores han montado un blog sobre el libro que se puede consultar aquí: http://libroiso20000.blogspot.com/
Durante las próximas semanas voy a hacer una especie de maratón formativa que me va a dejar seco: voy a impartir la friolera de 5 cursos de temas diferentes a personas diferentes y uno de estos cursos tiene como título "Inmersión en Estándares de Gestión TIC", en el que se da una visión de ave rapaz sobre ITIL, COBIT, ISO20.000, CMMI-DEV, CMMI-SVC, ISO27001, SIX SIGMA y, lo más interesante, cómo integrar, mezclar, combinar y aprovechar todo esto para "tunear" las prácticas de ITSM que tengas montada o quieras montar.
Evidentemente, esto es a vista de ave rapaz, y no se puede entrar en mucho detalle, principalmente por dos razones: la primera y más importante, el tiempo. ¿Te imaginas la magnitud que tendría una formación detallada en todas estas áreas?. La segunda razón es el tamaño de nuestras cabezas: tanto conocimiento no cabe "de golpe y sin procesar" en la cabeza de nadie, empezando por la mía.
Pero claro, para poder preparar el curso he tenido que refrescar muchos conocimientos que tenía por ahí guardados y ampliar unos cuantos que no tenía (por ejemplo, CMMI-SVC, que aún no se ha publicado) y a base de pasarme horas estudiando y pensando en qué quería explicar y cómo lo quería hacer, he acabado pensando en que, a priori, parece que las tres grandes encajan bien entre ellas.
ITIL, COBIT e ISO27001 ya se han hecho cuadrar, tanto en el artículo "Combinando Estándares" de este blog como en las publicaciones del itSMF e ISACA que en él se referencian. Pero hay dos nuevos players en la arena: CMMI-SVC e ISO 20.000
El título de este artículo viene precisamente del gran peligro que puede suponer la lectura en diagonal de tanto estándard sin pararnos a mirar aquella parte de los manuales que todos nos saltamos cuando ya sabemos un poco: el glosario
Si nos dicen que CMMI-SVC está orientado a proporcionar una guía hacia el modelo de madurez en la provisión de servicios y que entre otras, las áreas de proceso que incluirá son la gestión de la capacidad o la gestión de problemas, pensaremos de forma inmediata que ya tenemos (al fin!) un modelo de madurez serio para ITIL, ¿no?
Hasta aquí, es lo más normal del mundo. El problema viene cuando de repente piensas "pero... ¿se están refiriendo a lo mismo? ¿TODOS se refieren a lo mismo?"
La clave de todo es el servicio: ITSM, ITIL, ISO20.000 y CMMI-SVC están orientadas todas a servicios IT, por lo que si no nos miramos el glosario, están todas orientadas a la idea que tenga el lector de lo que es un servicio IT. Esta forma de verlo era válida hasta hace poco, en que no había certificación; pero a la que aparece un "sello" que te certifica en ISO20.000 o en CMMI nivel 3, es obligatorio que el concepto certificado sea exactamente el mismo, o las certificaciones no tendrían valor.
Así que me fui directo al glosario:
Service Support: ARG! No tiene definición de servicios en el glosario!
Service Delivery: One or more IT systems which enable a business process.
Planning to Implement: One or more IT systems that enable a business process.
COBIT 4: ARG! Tampoco tiene definición
A estas alturas ya estaba preocupado. De todas formas, por ahora no había entrado en los "cuerpos certificadores", así que las interpretaciones podían ser todo lo libres que uno quisiera (se acuerdan de aquello del "Estilo Campechano"? ).
El siguiente paso fue buscar en las áreas de certificación:
BS15000: ARG! No define el término service ni IT Service
ISO 20.000:1 o 20.000:2 ARG!!!! Tampoco define los términos.
Versión Española de la ISO 20.000 ¡¡Tampoco!!
CMMI-SVC: En las FAQS aparece algo...
The CMMI for Services team defines a service as a product whose primary value is delivered to a customer or end user in a form that is intangible, non-storable, and dependent on the direct application of labor.
Yo diría que la aproximación a servicio que está dando CMMI se parece bien poco a la que está dando ITIL en el glosario, ¿No?
Es más, el típico servicio (ITIL) que todo el mundo usa siempre en cada uno de los discursos es el correo electrónico, y eso, si bien podríamos decir que es intangible y quizás no almacenable (ja!) lo que seguro que no es es dependiente de la aplicación directa del trabajo, ¿No?
Es decir, mientras que ITIL habla de un servicio como una agrupación de hardware, software, comunicaciones, etc.., CMMI habla de servicio como lo que normalmente entendemos como "Servicios Profesionales": mantenimiento de equipos, gestión de la red, formación, etc.
¿Serán mapeables estos dos estándares?
Seguramente los harán mapear, porque hay el esfuerzo de mucha gente en juego. Pero gestionar, medir, evaluar y administrar un servicio tecnológico no tiene nada que ver con hacerlo con un servicio profesional.
¿Y las ISO ?
Esa es mi gran duda. Me parece haber leido en algún sitio que las ISO20000 están orientadas a Servicios TI y eso significa (al menos bajo mi punto de vista) un servicio al estilo ITIL.
Ahora bien... hago dos promesas formales:
Con respecto a este último punto, prometo escribir algún día un post: los servicios al estilo CMMI, los servicios profesionales, deben ir en la Carta de Servicios (documento para el cliente).
Los resultados de la Primera Encuesta GobTIC se presentaron en un post de finales de Noviembre. Entre las preguntas que se hacían en aquella encuesta había una que parecía muy inocente: "¿Todos los procesos para un servicio o todos los servicios para un proceso?" y el resultado fue que el 56% de los participantes escogió la opción horizontal: implementar un proceso para todos los servicios.
Estos días me he dedicado a leer documentación atrasada que tenía y había varios temas relativos a la todavía por estrenar ISO/IEC 20000 y su norma UNE correspondiente y a medida que iba leyendo me iban surgiendo preguntas y dudas que he ido tratando de resolver poco a poco.
La principal preocupación que me iba entrando es que la norma requiere que para obtener la certificación tengas todos los procesos de la ISO en marcha (y bien) y eso es mucho trabajo. Además, iba yo pensando que eso es, en realidad, imposible: un servicio que nuevo, con un bajo nivel de madurez es posible que no cumpla todos y cada uno de los procesos en el momento de la auditoría, ya que la implantación (o, digamos mejos, la incorporación) del servicio es un proceso largo... ¿podría ser revocado un certificado si se detectan no conformidades graves en un servicio de nueva implantación?
Por otra parte, iba pensando en aquellos entornos en los que se dan casos de externalizacion de diferentes áreas de los servicios y de los procesos a uno o varios proveedores. ¿Cómo se haría la certificación en estos casos?
La respuesta llegó de casualidad, leyendo un post en el foro del itSMF España, donde Ana Ramos daba un enlace a http://www.isoiec20000certification.com y en este website encontraba el documento estrella: las Scoping Guidelines en las que se explica algo que a mi entender es de una importancia capital y sin embargo tiene pocas referencias en la literatura que he consultado: el documento al respecto del ámbito o alcance de la certificación que se debe acordar previamente con la entidad certificadora y que será el que indique precisamente el alcance que tiene el certificado.
En estas guías aparecen los conceptos de proveedor interno, proveedor externo, organización cliente, localización geográfica, etc. y se dan varios ejemplos muy clarificadores al respecto de qué modelos de colaboración son certificables y cuáles no.
Ahora bien, ¿Qué tiene que ver todo esto con el orden de implementación? Pues resulta que la clave (lógicamente desde el punto de vista de la ISO/IEC 20.000) es que debes tener todos los procesos implementados, pero es el documento de ámbito el que regula sobre qué se aplican estos procesos y por lo tanto una aproximación "horizontal" como la que se proponía en las encuestas (un proceso para todos los servicios) no permite la certificación hasta no haber completado toda la implementación (todos los procesos para todos los servicios) mientras que una implementación "por columnas" (es decir, uno o más servicios, todos los procesos) nos permitiría obtener el sello limitado a los servicios que hayamos definido en el documento de ámbito de una forma gradual e ir (con los años) añadiendo nuevos servicios al documento de ámbito a medida que los vayamos madurando.
De esta forma, llegamos a la conclusión de que, si estás pensando una posible certificación sobre la ISO/IEC 20000, quizás la forma adecuada de implementar tus procesos sea definiendo primero el ámbito del proyecto de implantación (y del proyecto de certificación), luego hacer procesos sobre este ámbito y por último a la vez que entramos en la rueda de maduración y mejora de los procesos podemos ir entrando en la rueda de ampliación del ámbito.
¿Qué te parece?
