Publicada la nueva ISO 20000:2011

Ya tenemos nueva versión de nuestra querida ISO 20000:2011 “Information Technology – Service Management”, o lo que es lo mismo, ha eliminado de su título las palabras “Tecnologías de la Información” para simplemente hablar de gestión de servicios, aunque siga muy enfocado a servicios TIC.

Por lo tanto ya no vamos a implantar un SGSTI (Sistema de Gestión de Servicios de Tecnologías de la Información) si no que vamos a implantar un SGS (Sistema de Gestión de Servicios), haciéndole de paso un favor a la certificadora ‘SGS’, por aquello de la coincidencia de las siglas del sistema de gestión con las de la marca de la certificadora.

La norma también aumenta considerablemente de tamaño, pasamos de 22 a 36 páginas. Y por cierto, está en inglés hasta que AENOR tenga a bien traducirla (finales de este año o probablemente mediados de 2012).

Hay muchos cambios:

  • Cláusula 1: aquí lo más importante es que nos dice que el cumplimiento de las cláusulas 5 a 9 (ahora veremos de qué van) se puede demostrar ejerciendo el gobierno de los procesos, aunque estos sean operados a través de un tercero (proveedor o cliente). La cláusula 4 (el PDCA) debe cumplirlo sí o sí el proveedor del servicio (la empresa que se certifica o implanta un SGS, vaya).
  • Se establecen requisitos para definir un alcance correcto.
  • Hay más términos y definiciones; ver cláusula 3.
  • EL PDCA es mucho más claro, más detallado y está más estructurado. La cláusula 4 ahora es todo el PDCA; me gusta. No hay grandes nuevos requisitos (salvo uno que ahora comentaré), pero la integración con 27001 o 9001 es más directa ahora.
  • En el punto 4.2 se habla del “Gobierno de procesos operador por terceras partes”. Muy interesante.
  • Revisión por Dirección, en la cláusula 4.5.4.3: aquí si hay novedades, ya que POR FIN establecen requisitos claros para llevar a cabo dicha revisión. Este era uno de los puntos que generaba más debate con la ISO 20000:2005 ya que no había puntos objetivos para realizar esta revisión.
  • La cláusula 5 es el diseño y la transición (como ITIL) de nuevos servicios o servicios modificados. Muy bien redactada y estructurada, establece muchos y nuevos requisitos para operar este proceso. Pasa de ocupar 3/4 de folio a ocupar prácticamente 2 folios, dividiéndose en “generalidades”, “planificación”, “diseño y desarrollo” y “transición”.

Hasta aquí el PDCA. En los procesos también hay muchos cambios, pero sólo comentaré los que considero más importantes o sorprendentes:

GESTIÓN DE NIVELES DE SERVICIO:

  1. Ahora obliga a tener un catálogo de servicios.

INFORMES DEL SERVICIO

  1. Sin cambios relevantes.

CONTINUIDAD Y DISPONIBILIDAD DEL SERVICIO

  1. Se divide en “requisitos”, “planes” y “monitorización y pruebas”.
  2. Detalla los requisitos que deben tener los planes. No hay mucho nuevo, ni nada raro.
  3. Especifica que el plan de continuidad y el de disponibilidad pueden estar integrados dentro de un único documento :O

PRESUPUESTOS Y CONTABILIDAD DE LOS SERVICIOS.

  1. Sin novedad en el frente, salvo la mejor redacción intrínseca a la nueva norma.

GESTIÓN DE LA CAPACIDAD

  1. La vida sigue igual. Especifica mejor la relación que tiene este proceso con la gestión de niveles de servicio, continuidad y disponibilidad.

GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN

  1. Se divide en: política, controles y cambios e incidentes.
  2. Detalla lo que debe contener la política a través de lo que debería hacer la dirección, con la voz “Management shall…”.
  3. Algún pequeño requisito para los controles, como que deben conseguir cumplir los objetivos de seguridad (obvio, para eso están).

RELACIONES CON EL NEGOCIO

  1. Aquí copio literal y que cada uno saque sus conclusiones “the service provider shall have a designated individual who is responsible for managing the customer relationship and customer satisfaction“. Hecha la ley, hecha la trampa (no digo más…).
  2. Novedad importante: para medir la satisfacción del cliente simplemente hay que coger una “muestra significativa” de los clientes y usuarios del servicio, no todos. Y no es que antes obligase a hacerlo con todos, pero tampoco decía que valía con una muestra.

GESTIÓN DE SUMINISTRADORES

  1. Ídem de lo del “individual who is responsible….” aunque en este caso es para gestionar la relación con el suministrador, así como el acuerdo y el rendimiento del mismo.
  2. Especifica muy bien lo que debe tener el acuerdo con el suministrador; llega hasta el apartado ‘L’.

GESTIÓN DE INCIDENTES Y PETICIONES DE SERVICIO

  1. Introduce el concepto de “peticiones del servicio”, que hacía falta como el comer. Antes lo nombraba tímidamente dentro del proceso, pero sin grandes consecuencias prácticas. Ahora adquiere casi la misma importancia que los incidentes, debiendo cumplir prácticamente los mismos requisitos que un incidente.
  2. Para los incidentes graves no se queda simplemente diciendo que debe haber un procedimiento, si no que añade requisitos como por ejemplo que la alta gerencia debe conocerlos (…).

GESTIÓN DE PROBLEMAS

  1. Especifica cuándo registrar un “Error conocido”: cuando hayamos encontrado la causa raíz pero el problema no ha sido completamente resuelto. Antes esto pasaba sin pena ni gloria y cada uno lo hacía cuando quería o cuando decía ITIL, que es justo ahí, por cierto.

GESTIÓN DE LA CONFIGURACIÓN

  1. Especifica qué debe contener cada CI.
  2. Asociar a los CIs sus errores conocidos.

GESTIÓN DE CAMBIOS

  1. Hay que definir qué CIs estarán sujetos al proceso de gestión de cambios.
  2. Hay que establecer criterios para identificar cambios que puedan ocasionar grandes impactos en el servicio. Esos cambios deberán ser llevados a través de la cláusula 5 (verla más arriba), dándoles así mucha más importancia. Además, es de sentido común que un cambio que pueda tener un impacto importante sea gestionado como una modificación del servicio, con todos sus formalismos.
  3. La eliminación o la transferencia de un servicio debe ser gestionado como un cambio que potencialmente tenga un impacto importante en el servicio, es decir, con la cláusula 5.
  4. Especifica que deben actualizarse los registros de la CMDB justo después de implementar con éxito un cambio.

GESTIÓN DE ENTREGAS E IMPLEMENTACIÓN

  1. Pocas novedades. Simplemente dice que si es posible se prueben los planes de vuelta atrás.

Hay más cambios, pero a priori no tienen consecuencias prácticas. Ahora espero que entre todos podamos ir completando esta lista. Os animo a leer estos cambios que hay propuestos aquí e ir alimentando el post con más novedades o diferencias de criterio, ya que es una norma que acaba de salir y como siempre, habrá polémica :)

Saludos.

 

  1. Buenas!

    Muchas gracias por esta comparativa. Es muy interesante!

    Por empezar a comentar, a mí me llama mucho la atención un tema acerca del PDCA –> “Cláusula 1: aquí lo más importante es que nos dice que el cumplimiento de las cláusulas 5 a 9 (ahora veremos de qué van) se puede demostrar ejerciendo el gobierno de los procesos, aunque estos sean operados a través de un tercero (proveedor o cliente).”
    Entonces… esto significa que los servicios de outsourcing se pueden certificar, ya que por ejemplo, la gestión de la configuración, lo puede realizar el cliente, ¿no?

    Saludos cordiales!

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>