La gestión de los servicios ITIL y las normas

 

Introducción

A continuación vamos a dar el significado del acrónimo ITIL.

Information Technology Infrastructure Library, en español es una colección de libros que tratan las tecnologías de la información.

ITIL se basa en las buenas prácticas que van a permitir trabajar más eficazmente, dentro de los equipos informáticos.

El objetivo de este primer capítulo es recordar las buenas prácticas ITIL. Se abordará la gestión de servicios, su importancia, su necesidad de implementación para un departamento informático, los grandes principios del enfoque y los actores asociados.

Para permitir una mejor comprensión entre todos los actores del enfoque, las buenas prácticas del enfoque ITIL definen una serie de términos: a partir de este primer capítulo, se van a observar los principales términos utilizados por el enfoque en las diferentes versiones V1, V2, V3 y 4. Este vocabulario será enriquecido a lo largo de este libro y en particular, con los nuevos términos definidos por ITIL 4.

La gestión de servicios

1. Presentación

Desde hace mucho tiempo, la informática se ha centrado en una cultura orientada a "proyectos" y ha evolucionado hacia una cultura orientada a "servicios". La cultura orientada a proyectos es la capacidad de la informática de implementar nuevas funcionalidades relacionadas con las nuevas necesidades de negocio, una legislación nueva, los avances tecnológicos. Respecto a la cultura orientada a servicios, se trata de la capacidad de producir el servicio solicitado con el nivel de calidad solicitado, controlando los costes y los riesgos.

La cultura orientada a servicios representa tres puntos importantes en el enfoque de las buenas prácticas ITIL:

• Alinear los servicios informáticos con las necesidades de sus clientes
• Mejorar la calidad de los servicios informáticos
• Controlar los costes de la oferta de los servicios informáticos

La cultura orientada a servicios está en el centro de la informática, el cliente y las ramas de negocio de la empresa.

Lo principal en la gestión de servicios, es entender correctamente la noción de servicio.

2. La noción de servicio

La noción de servicio es un medio de proporcionar valor a los clientes, facilitando los resultados que desean obtener, sin concentrar toda la responsabilidad en los costes o los riesgos.

En otros términos un servicio es una aplicación que funciona en una infraestructura, con la documentación asociada, la formación adecuada, un soporte establecido, así como la asistencia a los usuarios y sobre todo, un compromiso sobre un resultado. Un servicio, es un compromiso de resultado de la informática frente a sus clientes, frente a las unidades de negocio de la empresa, asumiendo riesgos. Un servicio permite hacer más productivas las actividades que permiten la producción de entregables a las áreas de negocio, reduciendo las restricciones y los riesgos. Un servicio existe para dar VALOR a la empresa.

El valor tiene en cuenta dos nociones: la utilidad y la garantía.

La utilidad

La utilidad describe las funcionalidades del servicio y por lo tanto, las funcionalidades de la aplicación que soporta este servicio, es decir, lo que la aplicación debe hacer para entregar el servicio. La utilidad describe las especificaciones funcionales.

La garantía

La garantía describe el uso del servicio, es decir, cómo los usuarios van a utilizar el servicio. Por ejemplo, las horas de apertura del servicio (horario de oficina o veinticuatro horas a día) o la disponibilidad y continuidad del servicio. La garantía describe las especificaciones no funcionales.

3. La gestión de servicios

La gestión de servicios es un conjunto de disposiciones especializadas, que permiten proporcionar el valor a los clientes en forma de servicios. Estas disposiciones toman la forma de procedimientos, procesos y prácticas, cuyo objetivo es gestionar los servicios a lo largo de su ciclo de vida. El centro de la gestión de los servicios es la transformación de los recursos en servicios de valor añadido. Sin esta capacidad, una organización es un cúmulo de recursos con poco valor para los clientes y el resto de las partes que lo forman.

La palabra "gestión" incluye la planificación, la implementación y la optimización de la oferta y del soporte de los servicios informáticos.

La complejidad de la informática, su visibilidad en la empresa (visibilidad de los fallos de la informática), sus costes (la informática es cara, percepción o realidad), la concurrencia (las empresas de servicios informáticos, de alojamiento, de auto abastecimiento, etc.), la suma que una empresa o un negocio en la empresa, está dispuesto a pagar por una informática de alto rendimiento, todos estos puntos son preguntas a las que la informática debe dar su respuesta. Con la gestión de servicios, se va a posicionar como generador de valor, un valor diferencial para la empresa.

Para esto, debe ofrecer una visión clara de lo que la entidad informática puede proporcionar a las unidades de negocio de la empresa, es decir, saber identificar, formalizar y comunicar los servicios que se proporcionan a las unidades de negocio y lo que se podrá producir en el futuro. La entidad informática debe entender las verdaderas necesidades de las unidades de negocio, y esto implicará una apertura de la informática a sus clientes, a las unidades de negocio de las empresas y por lo tanto, estructurar su relación con los clientes. Abrir la informática a sus clientes, también significa centrarse en el valor añadido al negocio, proporcionando servicios disponibles y de calidad. La entidad informática analizará cómo ayudar a las unidades de negocio en sus actividades diarias. Se va a conducir por la satisfacción de sus clientes, es decir, deberá medir esta satisfacción de manera regular e intentar la mejora continua. De esta manera va a contribuir a mejorar la rentabilidad global de la empresa.

Todo esto pasa obligatoriamente por un mantenimiento de la motivación de los equipos informáticos. La orientación al cliente va a dar más sentido al trabajo proporcionado por los informáticos y un mayor reconocimiento de estos clientes, lo que fomentará la motivación de los equipos.

Por lo tanto, la informática se convierte en un valor estratégico esencial en la empresa.

Las normas

Las normas son documentos que definen las obligaciones, directivas o características. Las normas se dirigen a los productos o los servicios. Algunas de ellas pueden definir los procesos. Las normas que nos interesan en informática se elaboran por la ISO (International Standard Organization, en castellano Organismo internacional de estandarización). La ISO es una organización, de hecho una ONG, radicada en Ginebra y formada de 162 países. AENOR es el representante de España en la ISO.

Una norma tiene una vocación internacional y su objetivo es garantizar que los productos o servicios tengan un determinado nivel de calidad. Existe en la actualidad más de 19.000 normas internacionales, reuniendo a todos los sectores. 

Una norma se elabora por grupos de expertos de la ISO y una vez finalizada, se vota en una asamblea plenaria. Desde el momento en el que se ratifica, se convierte en una referencia a nivel internacional.

Una norma normalmente tiene un carácter obligatorio y va a hacer necesario una certificación. La ISO no es un organismo de certificación. En España, AENOR se encarga de la certificación de las organizaciones en el dominio que afecta a este libro, es decir los sistemas de gestión.

Una norma, a través de su carácter obligatorio, hace necesario que se implemente de manera exhaustiva, todas las obligaciones y directivas que se definen.

1. La norma ISO 9001

La norma ISO 9001 forma parte integrante de una serie de normas relativas a los sistemas de gestión de la calidad, sea cual sea el sector de actividad (informático u otro): se trata de las normas llamadas ISO 9000. Describen las obligaciones necesarias para la existencia de un sistema de calidad. Estas obligaciones dan el marco de referencia para una certificación de empresa.

La norma actual en vigor, ISO 9001, tiene fecha de 2008.

La norma ISO 9001 versión 2008, defiende un enfoque por procesos para el desarrollo e implementación de un sistema de gestión de calidad, dentro de la organización. Este enfoque se completa por una obligación de mejora continua, para obtener una mejor adecuación con las nuevas necesidades de la empresa. Para obtener un funcionamiento óptimo, es indispensable supervisar, medir y analizar los resultados de los procesos.

Se pide poner en marcha un sistema que permita:

• entender las obligaciones de los clientes y alcanzarlas,
• considerar que los procesos deben generar resultados y beneficios,
• medir el grado de consecución de estos resultados y beneficios, a través de indicadores de rendimiento (consecución de la eficacia),
• mejorar continuamente los procesos (mejorar la eficiencia).

La norma presentada se basa en ocho principios:

• orientación al cliente,
• el leadership,
• la implicación del personal,
• el enfoque por procesos,
• la gestión por enfoque de sistema,
• la mejora continua,
• la toma de decisiones sobre indicadores reales,
• las relaciones mutuas entre las partes integrantes.

2. La norma ISO 20000

La norma ISO 20000 es una norma internacional sobre la gestión de los servicios informáticos. Es el resultado de la norma BS 15000 del British Standards Institute. Esta norma se basa en un enfoque por procesos, definidos en las buenas prácticas ITIL versión 2 (ver la sección ITIL versión 2, de este capítulo). La norma ISO 20000 se aplica únicamente al sector de la informática, al contrario de lo que sucede con la norma ISO 9001, que se aplica a todos los sectores del mercado.

En España, AENOR acompaña a las empresas en la certificación ISO 20000 de sus establecimientos. Por supuesto, esta certificación se facilita si la entidad informática ya ha puesto en marcha las buenas prácticas ITIL (versión 2 o versión 3) o si la empresa está en un enfoque ISO 9001 o ya tiene la certificación ISO 9001.

La implementación de la norma ISO 20000

La norma ISO 20000 requiere la implementación de trece procesos, definidos en las buenas prácticas ITIL V2, e igualmente respetar un determinado número de obligaciones. El siguiente esquema muestra el posicionamiento de estos trece procesos.

Los procesos se agrupan en cinco dominios:

• la oferta de los servicios:

• la gestión de los niveles de servicio,
• la gestión de la continuidad informática y la gestión de la disponibilidad,
• la gestión de la capacidad,
• la gestión de la seguridad,
• la gestión financiera (presupuestación y contabilidad),
• la gestión de los informes de servicios.
• la gestión de las relaciones:
• la gestión de los proveedores,
• la gestión de las relaciones comerciales.
• la resolución:
• la gestión de incidentes,
• la gestión de problemas.
• El control:
• la gestión de cambios,
• la gestión de las configuraciones.
• la entrada en producción:
• la gestión de las entradas en producción.
• Las obligaciones tratan los tres aspectos siguientes:
• la responsabilidad de la dirección,
• la gestión de la documentación,
• el nivel de competencia del personal y la formación.

La certificación ISO 20000 hace necesario un gran esfuerzo de implementación, ya que además de la implementación de los trece procesos y los requisitos, debe mostrar la relevancia de, al menos, un ciclo de mejora del conjunto.

Los estándares

¿Qué es un estándar?

Para los anglosajones, no hay diferencia entre una norma y un estándar, ya que la palabra "norma" se traduce en inglés por "estándar". Un estándar generalmente es un documento elaborado por una empresa o grupo de empresas y que establece las obligaciones, especificaciones y líneas directrices que se deben aplicar. Generalmente, esta empresa o grupo de empresas tienen un carácter dominante en su mercado.

Un estándar se va a imponer de facto en el mercado. Un estándar responde normalmente a objetivos comerciales. Normalmente se impone por las industrias.

Un estándar afecta a los productos o servicios. Garantiza un determinado nivel de utilización de estos productos o servicios.

Un ejemplo de estándar en informática es el smartphone. El iPhone de Apple se convirtió en un estándar, por su aspecto, su navegación, su empleo y su modo de utilización. Otro ejemplo un poco más antiguo, la conexión de red fija Ethernet, que fue uno de los primeros estándares informáticos, creado por Xerox, Intel y DEC.

1. Six Sigma

Respecto a la calidad y la mejora de los procesos, se debe mencionar un estándar: el método Six Sigma. Este método se definió por Motorola a finales de 1980 y rápidamente se aplicó a todos sus proyectos. Six Sigma se basa en el concepto de la rueda de Deming (ver el capítulo sobre la mejora continua) y tiene como objetivo mejorar la eficacia y el rendimiento de los procesos.

El método se basa en cinco etapas, identificadas con el acrónimo DMAIC (Define, Measure, Analyze, Improve, Control en inglés):

• Definir: los procesos, siguiendo un diagrama de flujo de tipo SIPOC (Supplier, Input, Process, Output, Client; en español, proveedores, entradas, procesos, salidas y clientes).
• Medir: las herramientas de medición y análisis.
• Analizar: el valor añadido aportado por los procesos.
• Mejorar: la planificación de las acciones.
• Controlar: la planificación de las experiencias.

Los repositorios

Los repositorios son los marcos de trabajo que hacen las recomendaciones para acceder a las mejores características de un producto o a las mejores prácticas de un negocio. Los repositorios normalmente son una selección de normas (o de extractos de normas), experiencias sobre el terreno (de buenas prácticas) y de trabajos teóricos, que están estructurados. Normalmente son públicos. Los repositorios afectan a los productos, los servicios y las organizaciones.

El interés de un repositorio es proporcionar un marco y unas herramientas para medir la posición del producto, del servicio o de la organización dentro de este marco. Por otro lado, podemos compararlos con otros productos, servicios u organizaciones. Se podrá realizar lo que los ingleses llaman del "benchmarking"). La comparación y por lo tanto la medición, se basa en el rendimiento, el cumplimiento, la efectividad o la eficiencia.

Un repositorio también es una garantía de neutralidad e independencia. Le permitirá dar un paso atrás y tener una determinada legitimidad para explicar las situaciones, los funcionamientos incorrectos o exitosos.

Más adelante hay una descripción de los repositorios que se usan en informática de manera más habitual.

2. El enfoque COBIT

COBIT (Control Objectives for Information and Related Technologies), es un enfoque que permite la auditoría y evaluación de los servicios informáticos de una empresa, con el objetivo de observar el rendimiento y la solidez en términos de seguridad y cumplimiento. Forma un repositorio completo que permite poner bajo control el conjunto de operaciones relacionadas con la información. Ayuda a los dirigentes a entender y gestionar los riesgos relativos a la informática.

COBIT es un modelo basado en un enfoque por procesos, lo que permitirá una complementariedad con el enfoque ITIL V3.

Este enfoque se ha llevado a cabo desde la década de 1990 por una asociación estadounidense, ISACA. COBIT es muy utilizado como herramienta de cumplimiento, en particular con el repositorio SOX (Sarbanes Oxley) y numerosas normas y estándares. La versión 4 llegó a España en 2007.

La formalización COBIT

COBIT es un enfoque basado en los procesos, 34 en total, que se agrupan en cuatro áreas principales:

• la planificación y la organización (diez procesos),
• la adquisición y la implementación (siete procesos),
• la oferta del servicio (trece procesos),
• la supervisión y la evaluación (cuatro procesos).

Para medir la madurez de los procesos, el modelo COBIT se basa en una evaluación de desarrollo de seis niveles:

• inexistente,
• inicializado, pero caso por caso,
• reproducible pero intuitivo,
• procesos definidos,
• gestionado y controlado,
• optimizado.

Para concluir, COBIT es un marco de referencia para gestionar la administración de la informática. Cada vez es más utilizado en las empresas y los organismos oficiales.

3. El modelo CMMI

El modelo CMMI (Capability Maturity Model Integration) sirve de referencia para evaluar el nivel de madurez de las actividades de ingeniería informática y en particular, las actividades de desarrollo de las aplicaciones. CMMI fue creado por el Software Engineering Institute del Carnegie Mellon University de los Estados Unidos, en los años 80 para aprender y medir la calidad de la oferta informática, en el departamento americano de defensa.

Este modelo de referencia evolucionó en la década de 1990, para respaldar todas las buenas prácticas de la ingeniería de software. A partir del año 2000, CMMI se abre a todos los sectores de mercado y englobó el conjunto de problemas de la ingeniería informática, como la gestión de los recursos humanos o el soporte de los componentes de tipo hardware. El modelo CMMI evolucionó en 2006 a través de su versión 1.2, que define una escala de medición de la madurez de cinco niveles, así como los indicadores necesarios para evaluar las actividades para alcanzar estos niveles.

Su idea principal es que la calidad de un producto se determina fundamentalmente por la calidad del proceso utilizado para diseñarlo y mantenerlo.

Es complementario a las buenas prácticas ITIL y normalmente, estos dos enfoques se implementan juntos en muchas empresas grandes.

La madurez según CMMI

La madurez es el grado al que una organización ha llevado la implementación explícita y coherente de los procesos que se documentan, gestionan, miden, controlan y mejoran de manera continua.

Un nivel de madurez se corresponde con el grado de consecución de un nivel uniforme para un grupo de proceso. Hablamos de nivel de "capacidad" ("capability level" en inglés, de ahí la C de CMMI): capacidad de conocer, capacidad de actuar. El nivel de capacidad es la medición del logro de la meta de un proceso. 

Descripción del modelo

El modelo CMMI (versión 1.2) identifica cinco niveles de madurez y veintidós dominios de proceso.

• Nivel de madurez 1: Inicial

No hay procesos establecidos o bien existen como documento, pero no están implementados. No hay ni supervisión, ni evaluación de eficacia o de rendimiento. Cada proyecto se realiza por un individuo: su gestión se deja a su propia iniciativa.

• Nivel de madurez 2: Reproducible

Para cada proyecto, hay documentos de proyecto (planificación de desarrollo, plan de garantía de calidad, especificación de las pruebas, documento de arquitectura, etc.). El jefe de proyecto es responsable de su proyecto: es responsable de la actualización de los documentos del proyecto a lo largo de todo el ciclo de vida del proyecto. Él capitaliza de un proyecto a otro.

• Nivel de madurez 3: Estándar

Se establece una estandarización de las prácticas y de los documentos. Existe un estándar para cada documento y se ha establecido un sistema de calidad que define una estrategia de calidad. Existe un plan de mejora para mejorar cada proceso.

• Nivel de madurez 4: Controlado

Los proyectos se gestionan sobre la base de objetivos cuantitativos que dirigen la calidad. Se tienen en cuenta las obligaciones de los clientes en términos de calidad.

• Nivel de madurez 5: Optimizado

Los procesos, gestionados sobre la base de objetivos cuantitativos de calidad (nivel de madurez 4), están en mejora constante con el objetivo de optimizar los recursos y los medios, y responder a las necesidades futuras (evoluciones solicitadas por los clientes, nuevas tecnologías, evolución del mercado, etc.).

4. El método ágil

a. La Agilidad

El método ágil es un enfoque de gestión de proyectos, que va en contra con los métodos tradicionales de gestión de proyectos secuenciales de tipo "ciclo en V" o en cascada (waterfalls en inglés). El método ágil da visibilidad al cliente, implicándole desde el inicio hasta el final del proyecto, por la implementación de un proceso iterativo e incremental. Hablamos de que la necesidad expresada por el cliente no está escrita en piedra, y los cambios que pueden producirse, deben poder integrarse a lo largo de todo el proyecto.

El método ágil parte del principio de que detallar las especificaciones del producto completo, planificar completamente todos los desarrollos de manera previa, es contraproducente ya que hay imprevistos que seguramente van a aparecer e interrumpir la funcionalidad y la planificación.

Partimos de un primer objetivo, con las funcionalidades mínimas, alcanzables a corto plazo, visible para el cliente y seguidamente, por medio de iteraciones continuas, las funcionalidades se enriquecen hasta alcanzar el objetivo final. En cada iteración, se especifica, desarrolla, prueba, integra y valida con el cliente. Por lo tanto, es un enfoque empírico que permite proporcionar una solución optimizando los plazos para responder a la noción de "Quick to market" y "Time to market": más rápido y en el momento en producción.

De esta manera, el método ágil implica mucha flexibilidad y evita el efecto túnel de la gestión de proyectos de tipo "ciclo en V".

El método ágil ya es bastante antiguo. La primera implementación documentada data de 1993, es el método SCRUM. Se especifica en el "manifiesto ágil" en 2001, que le dio toda su relevancia.

Los grandes principios del método ágil son los siguientes:

• La satisfacción del cliente, entregando rápidamente y de manera regular versiones utilizables, con funcionalidades de alto valor.
• Tener en cuenta las nuevas necesidades expresadas por el cliente o al menos, la escucha positiva de estas nuevas necesidades.
• El cliente y los usuarios trabajan de manera conjunta y diariamente con los desarrolladores a lo largo de todo del proyecto, lo que motiva a unos y otros y mejora la transmisión de la información.
• La eficacia de los equipos se mide de manera regular, lo que puede implicar cambios en los métodos de trabajo.

b. El método SCRUM

Un proyecto que sigue el método SCRUM, se basa en "SPRINTS", es decir, iteraciones. Un SPRINT comienza con una reunión de planificación que define los elementos prioritarios (funcionales y/o no funcionales), que se deben introducir en la versión anterior en un plazo razonable. Las "MELEES" (reuniones diarias cortas de quince minutos máximo), permiten hacer un estado de situación entre todos los actores: algunos elementos realizados en el día, qué elementos se van a realizar antes de la siguiente melé, cuáles son los puntos de bloqueo o de retraso. Al final del SPRINT, una "revisión de SPRINT" presenta las funcionalidades realizadas durante esta etapa, y una revisión de "Retrospectiva del SPRINT" pone el foco en los puntos a mejorar (productividad, calidad, condiciones de trabajo, etc.).

c. Los principios DEVOPS

Los principios DEVOPS aparecieron en 2007 para permitir acercar el mundo del desarrollo al mundo de las operaciones, de ahí el acrónimo DEVOPS (las tres primeras letras de la palabra "development" en inglés y las tres primeras letras de la palabra "operation", explotación en inglés). Se trata de aplicar el método ágil al conjunto de las aplicaciones informáticas y a todos los equipos, desde el desarrollo hasta la producción.

Los grandes principios de DEVOPS son los siguientes:

• Un desarrollo regular de las aplicaciones.
• Pruebas muy tempranas en la cadena de la oferta de las aplicaciones y sobre todo, en entornos parecidos a los de producción.
• Una integración continua.
• Iteraciones más cortas posibles para la mejora, basadas en los feedbacks de los usuarios.
• Un control de la calidad en producción, con indicadores apropiados.

Los principios de DEVOPS se retoman con fuerza en el enfoque ITIL 4. Se va a ver a partir del capítulo Los grandes principios de ITIL 4, de este libro.

5. El modelo PRINCE 2

PRINCE 2 es un método de conducir proyectos. La OGC (Office of Government Commerce, que proviene del ministerio de comercio británico), es el propietario desde 1989 y hace que se aplique a los proyectos informáticos del gobierno británico desde esta época. En 1996, se extendió la última versión de PRINCE 2 e hizo más flexible para poder gestionar proyectos informáticos en todos los entornos y de cualquier tamaño. Ahora este método es de dominio público.

El método se basa en un determinado número de principios básicos como:

• un proyecto es un proceso con un inicio pero sobre todo con un final, claramente definidos,
• los proyectos siempre se deben controlar para que tengan éxito,
• el método tiene en cuenta los cambios del entorno, ya que tienen influencia sobre el éxito del proyecto.

La gestión de un proyecto se divide en cuatro fases:

• inicio,
• inicialización,
• ejecución,
• cierre.

Estas fases agrupan ocho etapas, también llamadas procesos:

• elaborar un proyecto,
• inicializar un proyecto,
• dirigir un proyecto,
• controlar una secuencia,
• gestionar la entrega de los productos,
• gestionar los límites de secuencias,
• cerrar un proyecto,
• planificar.

6. El modelo eSCM

El enfoque eSCM (enabled Sourcing Capability Management) es un modelo exhaustivo para gestionar todas las etapas de las actividades del abastecimiento y de la relación entre el cliente y el proveedor. eSCM ha sido respaldado por la universidad americana Carnegie Mellon (en Pittsburgh), en colaboración con grandes cuentas y compañías de outsourcing, desde hace diez años en los Estados Unidos. Kodak e IBM forman parte de las empresas que participaron de manera activa en la elaboración de este enfoque. En 2009, se crea ITSqc, que es una empresa nacida como extensión de la Universidad Carnegie Mellon, para promover los modelos de abastecimiento eSCM para los clientes y proveedores.

Este enfoque crea dos modelos de aptitud y métodos de medición y evaluación, que tienen la misión de mejorar las relaciones entre un cliente y un proveedor. Un modelo opera desde el lado cliente y el otro desde el lado proveedor. Los dos modelos son complementarios.

Estructura del modelo eSCM

Cada modelo tiene un número de prácticas. Una práctica contiene actividades que el cliente o el proveedor deben implementar, para gestionar el abastecimiento, desde su punto de vista respectivo. Cada práctica se ubica según dos planes: el ciclo de vida del abastecimiento y el dominio de aptitud.

El ciclo de vida del abastecimiento se descompone en cuatro fases:

• el análisis,
• el inicio,
• la oferta,
• la reversibilidad.

El dominio de aptitud se descompone en nueve dominios:

• la gestión de la estrategia,
• la gestión del management,
• la gestión de las relaciones,
• la gestión del valor,
• la gestión de cambios operativos,
• la gestión de los recursos humanos,
• la gestión del conocimiento,
• la gestión de la tecnología,
• la gestión de las amenazas.

Por lo tanto, una práctica pertenece a uno o varios componentes del ciclo de vida del abastecimiento y un dominio de aptitud.

El modelo se completa en una tercera dimensión, por los niveles de aptitud. Se definen cinco niveles:

• Nivel 1: realizar el abastecimiento
• Nivel 2: gestionar el abastecimiento con satisfacción
• Nivel 3: gestionar el rendimiento organizativo del abastecimiento
• Nivel 4: aumentar proactivamente el valor
• Nivel 5: mantener la excelencia

a. El modelo eSCM-CL para los clientes

Este modelo (eSourcing Capability Model - Client) es un modelo de aptitud del abastecimiento, que permite gestionar la relación con un proveedor desde el punto de vista del cliente. El objetivo de este modelo es:

• acompañar a los clientes para ayudarlos a mejorar su aptitud a lo largo de todo el ciclo de vida del abastecimiento,
• dar a los clientes un medio objetivo de evaluar la aptitud del proveedor.

La versión actual, eSCM-SP V1.1, apareció en 2006. Tiene 95 prácticas.

b. El modelo eSCM-SP para los proveedores

Este modelo (eSourcing Capability Model - Service Provider) es un modelo de aptitud del abastecimiento que permite a las organizaciones proveedoras gestionar la relación con un cliente y minimizar los riesgos asociados. El objetivo de este modelo es:

• acompañar a los proveedores para ayudarlos a mejorar su aptitud,
• evaluar la aptitud del proveedor con un medio objetivo,
• proponer un repositorio de trabajo con el cliente.

La versión actual, eSCM-SP V2.02, apareció en 2004. Tiene 84 prácticas.

Este enfoque es un verdadero complemento al enfoque ITIL V3.

7. LEAN

LEAN es un método que apareció a finales de los años 80, como consecuencia de los estudios generados por los trabajos del MIT, la célebre universidad americana. Este método se basa en un punto fundamental: la lucha contra el despilfarro, LEAN en inglés significa, sin grasa, delgado. Por lo tanto, buscaremos la productividad, el rendimiento, la calidad y eliminaremos los despilfarros y esto, en una mejora continua.

Este método se dirige a todos los sectores económicos y por supuesto, se aplica a la informática. Los japoneses han aplicado mucho este método, en particular el fabricante de coches Toyota.

Hay muchos libros que tratan sobre este tema, por lo que no voy a abordarlo. Solo quiero introducir, de manera muy resumida el LEAN Management, ya que esta manera de organizar el trabajo se retoma en parte en el enfoque ITIL 4.

LEAN Management tiene tres objetivos:

• Eliminar todo lo que no tiene valor y por lo tanto, los despilfarros, las funciones inútiles, así como los errores, los movimientos inútiles, etc.
• Eliminar la sobrecarga de trabajo provocada por procesos o procedimientos inadaptados.
• Evitar la irregularidad, para obtener un trabajo más rutinario, por lo tanto, más productivo.

LEAN Management se basa en la mejora continua y en el método de la rueda de Deming (ver el capítulo dedicado a ITIL 4, La mejora continua, de este libro).

Las buenas prácticas

Las buenas prácticas designan una colección de recomendaciones del mundo profesional y que están consensuadas sobre un dominio dado. Las buenas prácticas provienen del mundo de las empresas y no como sucede normalmente con los estándares y los repositorios, de una empresa dominante. Las buenas prácticas deben haber probado que aportan beneficios a las empresas, y esto en contextos diferentes (por ejemplo PYMES y grandes empresas, sector bancario, industrial, etc.). El interés de las buenas prácticas reside normalmente en la mejora de la calidad (a través del rendimiento y eficacia).

Las buenas prácticas normalmente se compilan en una guía de buenas prácticas. La mayor parte de estas guías, son responsabilidad de asociaciones o clubs de usuarios, que van a reunir las buenas prácticas, seleccionarlas, ponerlas en común y validarlas. Es necesario un trabajo de promoción alrededor de estas guías, para permitir su difusión e implementación.

El enfoque ITIL se basa en las buenas prácticas.

Una buena práctica se debe escribir por parte de un operativo para los operativos.

Las buenas prácticas ITIL

El enfoque ITIL es una selección de buenas prácticas muy operativas en materia de gestión de los servicios informáticos. Se generan por la OGC (Office of el Government Commerce, le ministerio de comercio británico), que tiene propiedad intelectual. Es un marco de trabajo, recomendaciones y no un estándar y menos aún una norma. El enfoque ITIL se basa en las experiencias vividas, es un enfoque pragmático de la informática, lo que llamamos conjunto de buenas prácticas en informática y de manera más particular, para la oferta de servicios informáticos.

El enfoque de buenas prácticas ITIL es abierto, no propietario y público. Por otro lado, es compatible con herramientas y software que pueden ser propietarios.

1. La historia del enfoque ITIL

Algunas fechas para entender mejor el enfoque ITIL:

• 1988: le CCTA (Central Computer Telecommunication Agency), agencia gubernamental inglesa, encargada mejorar la eficacia y calidad de los servicios informáticos centrales de los ministerios, crea las primeras bases del ITIL para la administración inglesa.
• 1990 a 1997: los primeros grupos de trabajo, basados alrededor de la itSMF (Information technology Service Management Forum, la asociación de los usuarios de la gestión de servicios y las buenas prácticas ITIL), reunieron profesionales del sector privado como los editores informáticos, de equipamiento en telecomunicaciones, los grandes bancos y agencias de seguros, los grandes nombres de la industria del automóvil, de la aviación y la energía.
• Un boom rápido en Inglaterra, como consecuencia del Market testing impuesto por Mrs Thatcher a las administraciones y empresas públicas.
• El enfoque ITIL se convierte en el estándar de facto en los Países Bajos y seguidamente, en los países nórdicos.
• A finales de los años 90, la itSMF aumenta el número de sus implementaciones en el mundo: Europa, Canadá, Japón, Australia, etc.
• 2001: se publica la versión V2 de ITIL.
• 2005: la creación de la itSMF España explicita el interés de las organizaciones públicas y privadas españolas, para la adopción del enfoque ITIL en España.
• Junio de 2007: se publica la versión V3.
• 2011: se corrige la versión V3 de ITIL (correcciones y evoluciones menores): se llama ITIL V3-2011.
• La itSMF se presenta ahora en casi ochenta países en el mundo.
• 2019: apareció el primer libro Los fundamentos de ITIL 4. AXELOS organizó el trabajo de unos diez expertos alrededor de una reformulación de las buenas prácticas de gestión de servicios. Trabajos revisados y adaptados por una comunidad de consultores ITIL de todos los rincones del mundo, voluntarios para esta actividad.

2. Las partes integrantes

Las partes integrantes del enfoque ITIL se estructuran de la siguiente manera:

• El propietario de los libros oficiales: la OGC (Office of Government Commerce, ministerio de comercio británico) es el propietario de los derechos de las versiones V1, V2 y V3 y actúa como editor de las publicaciones oficiales.
• La pieza clave de las versiones V1, V2 y V3: la itSMF (Information technology Service Management Forum), asociación de usuarios de la gestión de servicios, agrupa los expertos en gestión de servicios. La itSMF selecciona las buenas prácticas, las compila y las estructura. La itSMF asegura igualmente la promoción de la gestión de servicios y de las buenas prácticas ITIL, en su territorio.
• Respecto a la refundición ITIL 4, AXELOS es el gestor del proyecto, que reúne a una decena de expertos para escribir los diferentes libros, con el soporte de una comunidad de consultores voluntarios para la relectura. AXELOS es una empresa creada a iniciativa de la OGC, para gestionar y explotar las mejores prácticas recolectadas por la OGC.
• Los organismos de certificación: principalmente AENOR en España, son los organismos habilitados para entregar las certificaciones. Definen los cursos de formación de certificado, en el marco de las recomendaciones de AXELOS para ITIL 4. Son los garantes igualmente del contenido de cada tipo de formación de certificación entregado. Para terminar, validan a los formadores y organismos de formación que quieren dispensar las formaciones ITIL.
• Los organismos de formación y los formadores dispensan las formaciones ITIL: están validados por AENOR en España.
• Los expertos y consultores en gestión de servicios: la mayor parte están certificados en ITIL (ver el capítulo La puesta en marcha del enfoque ITIL).

3. ITIL versión 2

Aunque esta versión de ITIL apareciera en 2001 y desde 2007 la versión V3 es la referencia, ITIL 4 llega al mercado; es interesante presentarla ya que sigue estando muy implantada en España. Muchas empresas no han dado el paso de introducir las nuevas buenas prácticas de la versión 3 (por razones de estabilización de lo existente, falta de presupuesto, y quizás también de simplicidad) y por supuesto, ITIL 4 todavía no se ha implementado.

La versión 2 está formada de una decena de libros oficiales (cada uno con una portada de color diferente), de los que los dos más importantes (y más populares en España) son:

• El libro rojo: la oferta de los servicios (en inglés service delivery),
• El libro azul: el soporte en materia de servicios (en inglés service support)

En esta versión 2, hay otro libro interesante para el establecimiento de ITIL. Es el libro amarillo relativo a la gestión de la infraestructura (en inglés ICT management).

La oferta de los servicios incluye los cinco procesos tácticos que afectan al diseño y la oferta de los servicios:

• la gestión de los niveles de servicio,
• la gestión financiera,
• la gestión de la capacidad,
• la gestión de la disponibilidad,
• la gestión de la continuidad de servicios informáticos.

Normalmente se añade el proceso de gestión de la seguridad informática a la oferta de los servicios, aunque se describa en un libro específico.

El soporte en materia de servicios incluye cinco procesos operativos y una función que afecta a la entrada en producción, al mantenimiento y a la asistencia técnica y de negocio:

• la gestión de incidentes,
• la gestión de problemas,
• la gestión de cambios,
• la gestión de las entradas en producción,
• la gestión de las configuraciones,
• y la función centro de servicios (en inglés Service Desk).

4. El enfoque ITIL V3

a. Principios generales

Esta versión se presenta como una evolución principal respecto a la versión ITIL V2. Apareció en 2007. Los conceptos básicos se conservan en lo esencial, pero la estructura global se modifica. Los siguientes párrafos y el capítulo Repaso de los grandes principios de ITIL V3, van a explicar esta nueva estructura basada en el ciclo de vida de los servicios. El siguiente esquema da una visión de este ciclo:

El enfoque ITIL V3 está formado por cinco fases:

• la estrategia de servicios,
• el diseño de servicios,
• la transición de servicios,
• la explotación de servicios,
• la mejora continua de los servicios.

La versión V3 se ha modificado en 2011, con la introducción de evoluciones menores, correcciones y ajustes. Ahora hablamos del enfoque ITIL V3-2011.

b. Las publicaciones del enfoque ITIL V3

Las publicaciones que describen el enfoque ITIL V3, se estructuran en tres módulos:

• las publicaciones principales,
• las publicaciones complementarias,
• los artículos en Internet.

Las publicaciones principales

Las publicaciones principales son los libros oficiales editados por la OGC, que describen ITIL versión 3. Estos libros son cinco: la estrategia de los servicios, el diseño de los servicios, la transición de los servicios, la explotación de servicios y la mejora continua de los servicios. Hay que añadir un manual de introducción o de presentación resumida del enfoque ITIL V3.

Estos cinco libros van a describir las buenas prácticas para cada una de las fases del ciclo de vida de los servicios. Se va a encontrar información de los grandes principios de la fase, los procesos soportados, las funciones asociadas, los factores clave de éxito para la implementación de esta fase, los riesgos inherentes, las consideraciones técnicas, las recomendaciones de implementación y los roles de los actores clave.

Las publicaciones complementarias

Las publicaciones complementarias son una librería viva, compuesta por libros, artículos que evolucionan y se enriquecen cada día. Estos libros se producen por expertos, grupos de usuarios, miembros de la itSMF, universitarios, etc. Van a aportar claridad a las publicaciones principales, bajo un ángulo diferente: por ejemplo, van a responder a preguntas, como el enfoque ITIL en el mundo bancario o de telecomunicaciones, el enfoque ITIL desde el punto de vista de determinadas tecnologías (mainframe, Internet, etc.). Estas publicaciones van a completar las buenas prácticas ITIL V3, integrando por ejemplo las restricciones reglamentarias o los aspectos específicos del negocio. También encontramos los libros que dan información de la implementación del enfoque. Este libro forma parte de estas publicaciones complementarias.

Los artículos en Internet

Existe un determinado número de sitios web que tratan del enfoque ITIL. Los hay buenos y menos buenos. Es usted quien tiene que juzgarlos. Por el contrario, normalmente son sitios web comerciales. Solo mencionaré un único sitio web en este libro, no comercial. Es el de la asociación de usuarios ITIL, la itSMF, abierto a todos, con una parte reservada a los socios de la asociación, que da información de la garantía de los buenos usos, de las buenas prácticas. Esta es la dirección del sitio web a nivel mundial: www.itsmf.org

5. El enfoque ITIL 4

a. Introducción

Como se ha mencionado en el prefacio, el primer libro Los fundamentos de ITIL, apareció en marzo de 2019. ITIL 4 no se considera como la versión 4 del enfoque ITIL. El 4 significa la adhesión a la cuarta generación industrial. ITIL 4 adopta los grandes estándares de la tecnología y los incluye en las buenas prácticas, como ágil por supuesto, en particular SCRUM o DevOps, Lean, Cloud, etc. ITIL 4 va a permitir dar a las empresas los consejos que necesitan para dirigir los nuevos retos de la gestión de los servicios.

A partir del capítulo Los grandes principios de ITIL 4, el conjunto de este libro va a describir todas las buenas prácticas ITIL 4, las novedades y las relaciones con la versión ITIL V3.

b. Las publicaciones del enfoque ITIL 4

En el primer trimestre 2019, solo apareció el libro Los fundamentos de ITIL 4. En realidad, solo está disponible la versión inglesa "Foundation ITIL 4 Edition". Aporta los principios generales del enfoque, basándose en los conceptos de la gestión de servicios y la versión V3 de ITIL.

Hay otros libros que van a seguir para completar este primer libro. Hay en marcha trabajos promovidos por AXELOS, para finalizar los trabajos alrededor de las treinta y cuatro prácticas ("practices" en inglés) definidas en el enfoque ITIL 4. Los primeros libros AXELOS sobre estas prácticas, deberían aparecer a lo largo del año 2020.

Las definiciones del enfoque ITIL

1. Introducción

Las buenas prácticas ITIL V3 se basan, como otros procedimientos, en un enfoque basado en los procesos, que va a permitir estructurar la manera de trabajar y en las funciones, que están orientadas a la organización. Veinticuatro procesos componen el enfoque ITIL V3 de junio de 2007. La versión ITIL V3 2011 define tres nuevos procesos. A esto se añaden cuatro funciones.

En las buenas prácticas ITIL 4, no cuestionamos la noción de proceso, pero se extiende a la noción de prácticas ("practices" en inglés) con treinta y cuatro prácticas. Estas prácticas están enmarcadas por directivas.

2. La noción de proceso

a. Definición

Un proceso es una sucesión estructurada de acciones o actividades relacionadas, que permiten alcanzar uno o varios objetivos. Un proceso es medible. Genera resultados para un cliente y reacciona a uno o varios elementos desencadenantes específicos.

Por lo tanto, un proceso toma una o varias entradas definidas y la o las transforma en resultados (salidas). Un proceso debe incluir la definición de los roles y las responsabilidades de los actores, las necesidades respecto a herramientas y los controles de gestión necesarios para la oferta de resultados de manera fiable. Un proceso puede definir políticas, estándares, principios, actividades, procedimientos y modos operativos si es necesario.

Una vez definido, un proceso se debe documentar, poner en marcha y controlar. Una vez bajo control, se puede repetir y se convierte en manejable. Todo el interés de un proceso reside en el hecho de que se va a poder repetir las actividades y por lo tanto, ganar en rendimiento.

Un proceso es medible, es decir que tiene indicadores que van a medir su rendimiento. En particular, un proceso debe medir su eficacia y eficiencia. La eficacia es el grado de consecución de un objetivo. La eficiencia son los medios que el proceso va a implementar para alcanzar su objetivo y la calidad del resultado obtenido.

Cada proceso debe tener un objetivo claramente identificado y entendido por todos. Va a medir a través de un indicador de eficacia, si este objetivo se alcanza. Tan pronto como se alcance este objetivo, el proceso posicionará un indicador de eficiencia para optimizar los medios que utiliza, conservando el nivel de calidad solicitado.

Un proceso es transversal a la organización, a la empresa, incluso a las empresas: por ejemplo el proceso de gestión de incidentes se implementa en el departamento informático y sus diferentes entidades y los responsables externos del mantenimiento, los fabricantes externos, las empresas de outsourcing, los SSII, etc.

El enfoque por procesos no es un modelo de organización. Un proceso puede hacer que intervengan diferentes funciones de la organización y también del exterior de la organización. Un proceso debe ser independiente de la organización y de los cambios de organización.

Nota: no hay que confundir la noción de proceso, procedimiento y modo operativo.

• Un proceso: ver la definición más atrás.
• Un procedimiento va a detallar las tareas de una actividad de un proceso, indicando en particular los actores, los roles, las interfaces (entradas, salidas) de estas tareas.
• Un modo operativo consiste en una o varias consignas que se aplican a ejecución de un procedimiento sobre una herramienta. Un modo operativo está relacionado con una herramienta.

b. Los documentos asociados a los procesos

Existen cuatro documentos que van a definir los procesos y dirigir su ciclo de vida y su evolución. Se trata de la definición del proceso, el diagrama de flujo, la ficha resumida de rendimiento y el plan de mejora.

La definición del proceso

Es un documento que va a permitir definir el proceso para su implementación. Para esto, se debe encontrar un determinado número de información que va a estructurar este documento:

• La misión: lo que el proceso va a hacer y no va a hacer.
• El objetivo: se trata de identificar por una frase el o los objetivos que debe alcanzar. A este objetivo se le asocia un indicador de rendimiento. Es importante que cada proceso tenga un objetivo diferente de los objetivos del resto de procesos ya implementados.
• El perímetro: el perímetro funcional, organizativo, estructural, temporal, técnico, etc. sobre el que se va a intervenir.
• Las entradas y las salidas: los elementos desencadenadores del proceso en términos de datos y entregables.
• Las relaciones con los otros procesos: las dependencias con los otros procesos.
• La lista de acciones y actividades con sus entradas, las salidas y sus relaciones: lo que se esquematiza por un diagrama de flujo.
• Los actores del proceso: se especifica la misión y el rol de cada uno (con el modelo RACI), teniendo cuidado de identificar los equipos y/o los individuos. Sería necesario llegar a identificar personas físicas (Señor X, Señora Y).
• Los indicadores de rendimiento del proceso: son tipos de indicadores de progresión, conformidad, eficacia y rendimiento.
• Los riesgos relacionados con la implementación del proceso y su desarrollo.
• Las revisiones y las instancias del proceso: se trata de identificar todas las revisiones, sus objetivos, su frecuencia y qué actores van a participar.
• La terminología: normalmente es necesario definir claramente el vocabulario utilizado por el proceso. Un glosario normalmente es muy útil.

Este documento está, según el entorno de la empresa, en formato Word o PowerPoint. Un documento de texto (con frases) normalmente es más claro y preciso que un enfoque resumido (con palabras). Lleva un poco de tiempo la escritura de este documento de definición del proceso y facilita la implementación del proceso.

El diagrama de flujo

El diagrama de flujo es la representación resumida de las acciones y actividades de un proceso. Permite tener en una página una visión del encadenamiento de estas acciones y actividades y los elementos desencadenadores, así como entregables. 

Hay herramientas para construir diagramas de flujo. No es el objetivo de este libro hacer una lista. A pesar de todo, PowerPoint normalmente es una buena base (sencillo, fácil y conocido por todos), pero puede implicar dificultades para la actualización de los diagramas de flujo.

La ficha resumida de rendimiento del proceso

Esta ficha resumida sirve para evaluar el rendimiento del proceso. Siempre es mejor una ficha en una sola página, donde se verán aparecer los indicadores clasificados en cuatro categorías (progresión, conformidad, eficacia y eficiencia), las estadísticas si es necesario, los hechos se marcan en el periodo concreto, una conclusión en forma de plan de acción en la medida de lo posible. Se debe presentar la evolución respecto al periodo anterior. Los datos brutos normalmente no presentan interés, la variación es mucho más significativa.

Para los procesos importantes del enfoque ITIL, una ficha resumida de rendimiento por trimestre es recomendable.

El plan de mejora del proceso

Este documento es responsabilidad del propietario del proceso. Debe actualizarlo todos los años y someterlo para validación al administrador de los servicios. Los procesos tienen una vida propia, pero también una vida respecto al resto de procesos. Mejorar el rendimiento de un proceso sin tener en cuenta el resto, normalmente provoca una sobre calidad que incluso puede llegar a ser nefasta para el conjunto de la implementación del enfoque ITIL. Por ejemplo, ¿para qué mejorar el proceso de gestión de problemas, si la gestión de incidentes no sabe encontrar los incidentes recurrentes?

El plan de mejora del proceso implica la siguiente información:

• La estrategia de implementación del proceso y de las mejoras: recuerda cómo se ha puesto en marcha el proceso, identifica el objetivo final (por ejemplo, la certificación ISO 20000) y la manera de alcanzarlo.
• El plan de acción de mejora del proceso validado por el administrador de los servicios, identificando los resultados esperados, los recursos necesarios, los riesgos potenciales y las fechas de implementación.
• Las acciones de mejora no validadas por el administrador de los servicios: estas podrán servir de base para el siguiente plan.

3. La noción de procedimiento

Un procedimiento es un documento que describe la sucesión de tareas a realizar dentro de una o varias actividades de un proceso. Define al mínimo las entradas, entregables, roles y responsabilidades, así como los actores. Tendremos así el "quién hace qué ".

4. La noción de modo operativo

El modo operativo es un documento que adapta un procedimiento definido, a una herramienta particular.

5. La noción de función

La noción de función es una noción definida en las tres primeras versiones de ITIL. Por el contrario, no se aborda en el enfoque ITIL 4. En un contexto de agilidad de la empresa o de la entidad informática, la noción de función se puede juzgar como demasiado restrictiva, ubicando los diferentes actores en equipos diferentes: los desarrolladores entre ellos en la gestión de las aplicaciones, los técnicos de explotación en la gestión de las operaciones, etc. Solo el centro de servicios se conserva y define en una práctica específica.

Recordemos aquí la definición de función:

La función es una unidad organizativa que tiene sus recursos y sus medios propios, y que es responsable de producir un resultado. Los recursos y los medios son necesarios para la producción y el buen rendimiento de este resultado. Una función es de hecho un equipo o un conjunto de equipos con un jefe.

Una función, como un proceso, asegura una o varias actividades relativas a uno o varios procesos.

Una función es responsable de las herramientas que utiliza para su definición, su elección y su implementación. Una función sirve para estabilizar las organizaciones.

El siguiente esquema muestra la relación entre las funciones y los procesos. Para simplificar, las funciones son verticales e interproceso y los procesos son horizontales, transversales y transfuncionales.

Las buenas prácticas ITIL V3 definen cuatro funciones:

• El centro de servicios,
• la gestión de operaciones,
• la gestión técnica,
• la gestión de aplicaciones.

Claramente, el enfoque ITIL V3 no es un enfoque que dé un modelo de organización para un departamento informático. Las funciones dan un enfoque de los cuatro perfiles de personas que forman el departamento informático.

6. La noción de rol

Un rol es un conjunto de responsabilidades, actividades y dominios de autoridad asignados a un puesto. Este puesto se va a asignar a una persona física o a un equipo de personas. De esta manera, un rol será delegado a una persona física o a un equipo de personas.

Como regla general, un rol se define en un proceso o una función. A pesar de todo, determinados roles están relacionados directamente con los servicios proporcionados a los clientes. Por ejemplo, se van a encontrar los roles ostentados por el cliente y por sus usuarios.

Una persona física o un equipo de personas pueden desarrollar varios roles. Sin embargo, las buenas prácticas precisan que determinados roles sean incompatibles entre ellos. Se darán ejemplos en los capítulos siguientes. Por el momento, se puede citar el rol del administrador de incidentes, que en ningún caso debe estar ocupado por la misma persona que el de administrador de los problemas.

7. La matriz RACI

Las actividades de un proceso se usan por toda la organización y los equipos existentes. De esta manera, las actividades y los roles se deben establecer en correspondencia con los equipos existentes.

Para facilitar esta tarea, una matriz de referencia se utiliza para indicar los roles y responsabilidades en relación con las actividades. El modelo RACI es una de estas matrices.

El acrónimo RACI significa en inglés: Responsible, Accountable, Consulted, Informed. En español, Responsable, Aprobado, Consultado, Informado.

Más adelante hay una explicación de estos términos. Para simplificar la lectura, la A se explicará en primer lugar. Atención a las traducciones incorrectas de la R.

Accountable - Aprobar: la persona que es responsable del avance de la acción. La A es, como su nombre indica, el que debe rendir cuentas del avance de la acción. La persona que es A, asume la responsabilidad de la acción. Siempre hay uno y solo un A para cada acción.

Responsible - Realiza: la o las personas que realizan la acción. Hay al menos un R para cada acción. El A organiza como quiere externalizar la acción a realizar a la persona o a las personas que son R. Si esta o estas personas no cumplen sus objetivos, es la persona A la que asume la no consecución de los objetivos. En determinados casos, la persona A también puede jugar el rol de R. Esto no se recomienda, ya que entonces esta persona es juez y parte, pero la realidad muestra que es un caso normal.

Consulted - Consultado: la o las personas a las que se consulta para obtener un consejo. Este consejo se debe proporcionar y la persona que ha solicitado un consejo, debe tenerlo en cuenta. La consulta en sentido del enfoque ITIL, es tener en cuenta los consejos. Hay intercambio de información.

Informed: la o las personas que son I, son aquellas a las que se debe informar. Esto quiere decir que deben conocer la acción o su avance. No se pide nada más que esto, ninguna otra iniciativa, ni consejo por supuesto. Solo hay un único sentido de circulación de la información.

Los actores del enfoque ITIL

En las buenas prácticas ITIL, se definen determinados roles clave. Se trata de los roles de cliente, usuario, patrocinador, parte integrante, propietario de servicios, propietario de proceso, administrador de procesos, responsable de la gestión de servicios y administrador de la mejora continua.

Algunos de estos roles se presentan en las versiones ITIL V2 o ITIL V3 y otros únicamente en el enfoque ITIL 4, como el patrocinador.

1. El usuario

El usuario es la persona que utiliza a diario el servicio. Representa al cliente: transmite sus obligaciones al cliente. El usuario utiliza el servicio pero no paga por él. Sus relaciones con la informática se realizan únicamente a través del centro de servicios.

2. El cliente

El cliente es la persona o la entidad responsable de dar la orden, el gestor del proyecto (MOA). El cliente va a expresar las necesidades de negocio, negociar con la informática la solución que dará el servicio, validar (recepción de la solución con un proceso verbal) y pagar esta solución, así como el servicio que la soporta. El cliente también debe ser el representante de los usuarios. También puede ser un usuario de la informática. El cliente tiene a su disposición un canal de comunicación privilegiado con la informática, a través del proceso de gestión de niveles de servicios.

3. El patrocinador

El patrocinador es la persona que autoriza el presupuesto para la oferta de un servicio. El presupuesto se corresponde con el coste de los desarrollos y de la validación de la solución, pero también con el coste de la formación de los usuarios, de los equipos de soporte y de los operadores y tiene costes recurrentes de la oferta del servicio (infraestructura, explotación, mantenimiento, evolución, etc.). Esta noción se ha introducido en el enfoque ITIL 4.

4. Las otras partes integrantes

Las otras partes integrantes son el conjunto de otros actores que intervienen en la oferta de un servicio: los proveedores, como los proveedores de acceso de red, socios como las empresas de servicio implicadas en el desarrollo o los fabricantes, accionistas o incluso, personas independientes de la empresa en la entidad informática o del exterior de la empresa.

5. El propietario del servicio

El propietario del servicio es la persona A, accountable, del servicio. El propietario del servicio va a ser responsable de la definición del servicio, de su implementación, de sus mejoras y evoluciones, del ciclo de vida del servicio y de su fin de ciclo. De esta manera, va a ser la interfaz privilegiada del administrador del proceso de gestión del catálogo de servicios, para que este catálogo de servicios esté actualizado.

El propietario del servicio representa el servicio delante de todas las instancias de la organización. Está bajo iniciativa de las peticiones de evolución y se implica en todos los contratos relativos al servicio. Es el único responsable del servicio y es garante de desencadenar los procesos de escalado de problemas si es necesario. Es el encargado del servicio en términos funcionales, tecnológicos y organizativos.

El propietario del servicio se asegura de que se alcancen los objetivos del nivel de servicio contratado y responde a las obligaciones del cliente. Va a recuperar y gestionar la información proporcionada por los indicadores del servicio y elaborar los cuadros de mando y las estadísticas asociadas, para controlar el ciclo de vida del servicio.

6. El propietario del proceso

El propietario del proceso (en inglés process owner), es la persona A, accountable, del proceso. Es responsable de la definición del proceso, garante de su implementación y vigila su mejora. Es responsable del grado de consecución de los objetivos del proceso.

El propietario del proceso, en primer lugar va a definir con el administrador de los servicios (ver el párrafo siguiente), el perímetro de su proceso y luego va a construir la estrategia inicial del proceso y de su implementación. Va a definir las directivas y los estándares a aplicar.

Va a nombrar al administrador del proceso y definir con él las actividades del proceso. El propietario va a ser garante de que los roles definidos en el proceso tengan los actores identificados. En otros términos, es responsable de la asignación de recursos que soportan al proceso, actores y medios si es necesario y garantiza que existan en número suficiente y formados en consecuencia.

El enfoque por procesos es, en determinadas empresas, un gran cambio en la manera de trabajar. Es necesario para determinadas personas ser acompañadas y formadas en la noción de proceso.

Interviene frente al administrador del proceso en R, realización o C, consulta, para ayudarle a poner en marcha el proceso. En particular, el propietario del proceso debe asegurarse de que la documentación del proceso es correcta, está actualizada y está disponible para las personas implicadas.

También va a ser el garante de la elección de los indicadores clave de medición (KPI, Key Performance Indicators, indicadores de rendimiento clave). Estos indicadores son muy importantes, ya que van a permitir medir el rendimiento del proceso en términos de progreso, conformidad, eficacia y eficiencia (ver la sección relativa a la definición del proceso). Cuando el proceso está implementado, activa estos indicadores y analiza los cuadros de mando generados por el administrador de su proceso. Va a ser el encargado de toda la comunicación alrededor del proceso, ya sea hacia el resto de propietarios del proceso o hacia la informática o cualquier persona directa o indirectamente afectada, a través de los programas de sensibilización. Por lo tanto, gestiona todos los problemas que pudieran afectar a la buena ejecución de su proceso.

Otra responsabilidad del propietario del proceso es realizar de manera regular, auditorías de verificación de la eficacia del proceso e identificar las proposiciones de mejora, que negociará con el administrador de los servicios. Es el responsable de la existencia de un documento titulado plan de mejora del proceso. También debe revisar anualmente la estrategia definida para su proceso.

7. El administrador de servicios

El administrador de servicios es la persona responsable de declinar el enfoque ITIL en la empresa. Es Sr. o Sra. ITIL en la empresa. Esta persona es responsable de la definición de la estrategia de implementación de ITIL, de su implementación y del ciclo de vida de este enfoque en la empresa. Este administrador de los servicios es A, accountable para lo que se podría llamar el programa ITIL. Esta persona debería tener un grado suficientemente elevado en la jerarquía del departamento informático, para tener toda la legitimidad para poner en marcha este proceso.