Curso ITIL Fundamentos

Presentación del curso “Fundamentos de ITIL: Introducción a la gestión de sistemas de
información”
Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo
La Biblioteca de Infraestructura de Tecnologías de Información o ITIL es la aproximación de gestión

del servicio de tecnología de información más ampliamente aceptada y utilizada en el mundo. Soy
Carlos Burges Ruiz de Gopegui y en este curso creado en colaboración con Stéphane Kittler nos
vamos a centrar en la creación de servicios desde la perspectiva ITIL y en cómo la generación
de estos servicios ya sean para uso interno o externo tienen una serie de pasos y procesos
definidos por la forma de trabajo de ITIL que, sobre todo, está basada en el sentido común. ITIL es
un marco de mejores prácticas que se ha elaborado por los sectores público y privado a nivel
internacional. En él se describe cómo los recursos de tecnología de información deben ser
organizados para ofrecer un valor empresarial documentando los procesos, funciones y roles de su
gestión. La nueva edición ITIL 2011 es una versión de actualización de la versión de ITIL versión
3, la primera actualización importante desde 2007 y aborda una amplia gama de cuestiones
planteadas en el registro de control de cambios y resuelve los errores e incoherencias en el texto y
diagramas de toda la "suite". ITIL 2011 es una actualización de la certificación, no una nueva
versión. Es más, cuando termines el curso te darás cuenta de que ITIL no solo está pensado para
servicios tecnológicos, sino que sus buenas prácticas pueden utilizarse en casi cualquier situación
empresarial.
Comprender la metodología de gestión de los sistemas de información
Hola. Bienvenido a este curso sobre ITIL 2011: gestión de servicios informáticos en la empresa. En
este curso vamos a descubrir la metodología ITIL 2011, fruto de buenas prácticas, que te permitirá
gestionar mejor tus activos materiales, "software", pero también dotar a tu negocio u organización
de las mejores prácticas informáticas para que tanto tu empresa como el servicio informático o
departamento IT tengan éxito. En este curso veremos el vocabulario específico de esta
metodología, así como el modelo de trabajo en ciclos de vida. Al final tendremos la posibilidad de
poner en marcha las primeras buenas prácticas que te permitirán aplicar tus primeros
procesos ITIL para mejorar la satisfacción de tus clientes, de los usuarios y, sobre todo, para
ahorrar en recursos y mejorar procesos al proporcionar a los usuarios el servicio exacto que piden.
Conocer el origen de ITIL
El origen de ITIL nace en el mundo anglosajón y proviene específicamente de los británicos que, en

los 80, necesitaban encontrar una forma de ahorro sustancial en una parte de la economía, incluso
en toda su economía y servicio público. Así urgía entre otras cosas encontrar una metodología que
mejorase las funcionalidades y, sobre todo, su capacidad informática al mejor coste. Para ello se
realizó una encuesta en todo tipo de administraciones y de empresas: pequeñas,
grandes, medianas, públicas, privadas, las que necesitan mayor seguridad, las que
necesitan menos seguridad, con múltiples sedes, con una única sede, internacionales y locales. Así
se pidió a todos los participantes que indicasen sus mejores protocolos, sus mejores prácticas y lo
que les funcionaba cada día. A partir de todos estos datos se creó una metodología que
englobaba todas esas mejores prácticas. Se trata simplemente, tal y como se ha hecho, de dar
forma al sentido común. De este modo la idea de ITIL es simplemente retomar la experiencia
existente. No es un método completamente teórico inventado en el laboratorio, sino una
construcción a partir de la experiencia compartida. Como veremos más adelante, esto es
extremadamente importante para trabajar con ITIL.
Apoyarse en los puntos fuertes del método
Como hemos visto, esta metodología ITIL es sobre todo una metodología que está basada en el
empleo del sentido común. De hecho, como primera ventaja podemos utilizar experiencias vividas
en empresas que se compilan en un cierto número de acciones y ponerlas en práctica. Segunda
ventaja, y no es trivial, se trata de una metodología 100 % gratuita. Tercera ventaja, y algo siempre
muy interesante para las empresas u organizaciones, esta metodología es flexible, puedes
adoptarla total o parcialmente, rápidamente, poco a poco en pequeños proyectos. Adoptar solo
algunas partes e ir sobre todo adaptándolas específicamente al contexto empresarial en función
de tus necesidades. Cada empresa es diferente por su geografía, cultura, madurez, su actividad y
todo ello está previsto en la metodología ITIL. Por último, una ventaja más, nada desdeñable: ITIL
es capaz de absorber otras metodologías que ya se están utilizando en tu empresa u
organización. Por ejemplo, si haces gestión de proyectos con PMI o con Prince2, ITIL será
perfectamente capaz de integrarlo. Si trabajas con CMM para la gestión de la madurez de tus
procesos, ITIL lo absorberá. O si utilizas TOGAF u otras metodologías muy diferentes como Lean o
Six Sigma para el mundo industrial, ITIL los absorberá. ITIL absorbe sin ningún problema cualquiera
de tus prácticas. Estas prácticas pueden ser propias o estándares industriales y pueden proceder
de otros métodos a los que ya estás acostumbrado. Resumiendo en cuatro puntos: ITIL es
gratis. Integra buenas prácticas maduras y probadas basadas en la experiencia y el sentido
común. Es flexible para adaptarse al contexto de todos los tipos de organización y empresa. Y
adopta e incluso integra todo tipo de metodologías personales o comerciales que podrás usar
en tu empresa u organización.
Integrar ITIL con otros métodos
Otra riqueza que nos aporta esta metodología ITIL es la posibilidad de integrar otras
metodologías en su interior. Un ejemplo muy simple. Se te pide concebir un nuevo servicio pero
¿qué es concebir un nuevo servicio? Se trata simplemente de gestionar un proyecto. ITIL te va a
decir: "Trabaja en un modo de gestión de proyectos". ITIL nunca te dirá "Utiliza este o aquel
método de gestión de proyectos" sino que te dirá "Utiliza un método de gestión de proyectos que
te guste y que conoces. Puedes utilizar PMI, Prince2 u otros métodos de gestión de proyectos a los
que estás acostumbrado o que ya están implantados en tu empresa". Si necesitas una
metodología de análisis en tus proyectos, si necesitas una metodología de análisis en tus
procesos empresariales, puedes usar un método propio o emplear CMMI. Lo único que te pide ITIL
es que utilices lo que ya sabes utilizar y lo que ya funciona. Esto es lo extremadamente importante
y, aunque parezca mentira, es lo que dicta el sentido común. Si no dominas las metodologías que
empleas, te han salido muy caras y piensas que puedes hacerlo mejor, ITIL te dirá: "Usa el
sentido común y cámbialas si puedes". Si estás contento con las metodologías que
empleas, intégralas en ITIL porque esto no plantea ningún problema. Al contrario, si funciona, ITIL
lo valida. Serás tú quien demuestre que funciona y que de verdad ofrece un valor añadido.
Adaptar tus prácticas con ITIL
Siguiendo con las ventajas, tratemos ahora la adaptabilidad que propone ITIL. ITIL se va a adaptar
a contextos geográficos, culturales, empresariales, a contextos en términos de seguridad, de
derechos jurídicos, de funcionalidades que se le pidan, de tecnologías, a pequeños y grandes
sistemas. Es decir, ITIL tiene en cuenta todas las restricciones posibles e imaginables, incluso las
culturales. ¿Por qué? Simplemente, porque en un momento dado hubo personas que
se encontraron con estas dificultades y las superaron utilizando diversos métodos que habían
compilado a través de este método. Entonces no dudes, con ITIL siempre puedes encontrar una
solución completa o parcial que se va a parecer a los casos específicos a los que te
enfrentas. Tendrás que juzgar internamente cuál te conviene más, cuál te conviene menos y
tendrás que crear así la práctica adecuada para ese contexto específico.
Basarse en la experiencia vivida
Toda la riqueza de la metodología ITIL proviene de lo que es: una compilación de experiencias de

todo tipo de orígenes que han funcionado de verdad. No se trata de teorías que intentamos
imponer por la fuerza. No es, por ejemplo, como las normas ISO para las que tienes que hacer una
auditoría, una verificación y luego una certificación que pruebe que una organización es certificada
ISO. Aquí en el marco de ITIL tenemos un contexto particular. Hemos acumulado conocimientos
que se van sumando. Es a partir de esta base de conocimientos que hemos podido gestionar,
desplegar, administrar y hacer funcionar al máximo todos los servicios que hemos puesto en
marcha y, por ello, después los hemos añadido en el catálogo de buenas prácticas ITIL. Así, puedes
estar seguro de que se trata siempre, cuando recibas un consejo de metodología ITIL, de cosas que
ya hemos vivido y que ya se han implementado en empresas reales. Por ello es muy importante
recordar siempre y decirse que no, no se trata de alguien en una universidad que ha hecho una
investigación, sino de algo que viene directamente del mundo real.
Utilizar ITIL libremente
Otra buena noticia. ITIL está libre de derechos, es decir, no tienes que pagar ningún canon a
ningún organismo. ITIL pertenece, de hecho, al Ministerio de Comercio británico. Lo único que
vende este ministerio si los quieres comprar son los libros. Están a la venta en todas las librerías
"online", los puedes comprar, están traducidos a muchos idiomas y también los puedes conseguir
en PDF. Estos libros reagrupan todas las buenas prácticas de ITIL. También puedes, si quieres,
certificarte individualmente mediante exámenes. Sin embargo, ningún "software" o empresa,
menos aún una empresa, puede venir a la tuya y decirte: "Te voy a certificar en ITIL". Esto sería
completamente deshonesto. Ninguna empresa puede estar certificada en ITIL porque ITIL no
recomienda ninguna tecnología particular, ningún certificado y está libre de controles por parte de
intereses externos a la propia metodología. Ahí radica su interés y alcance universal.
Abordar las diferentes versiones de ITIL
La metodología ITIL ha tenido un ciclo de maduración a lo largo del tiempo. Sus primeros pasos
tuvieron lugar a finales de los 80, conforme se puso en marcha ITIL versión 1 que se componía de
unos 40 libros. A continuación, llegó la metodología ITIL versión 2, compuesta de 15 libros. Estos
libros se centraban en las diferentes funciones y diferentes procesos empresariales. La
metodología se mejoró progresivamente. Después, llegó la versión 3 y la versión 2011, que son
muy próximas una de la otra porque se pensó que fuese necesario cambiar los soportes de la
formación oficial. Ni siquiera se llegó a pensar que hubiese que cambiar demasiadas cosas en su
interior. Entonces se podría decir que la versión 3 y la versión 2011 son idénticas. La versión 3 de
ITIL o la versión 2011 están compuestas por cinco libros. Estos libros cubren las cinco etapas del
ciclo de vida de los servicios, esto es, el servicio estratégico, el servicio de concepción, el servicio
de transición, el servicio de operación y la mejora continua de los servicios. cada uno de estos
libros detalla precisamente estas etapas: entradas, salidas y las relaciones entre las diferentes
etapas de este ciclo de vida. Dispone también de mucha información adicional en Internet, es
decir, otros aportes que se hacen a ITIL a través de empresas que los han implementado con
independencia de que sean empresas que han aplicado ITIL o empresa de servicios y consultores
que ayudan a las empresas a implementar la metodología ITIL. Especialmente encontrarás mucha
información en foros especializados que suelen ser extremadamente útiles al compartir gran
cantidad de experiencias. No dudes en consultarlos.
Gestionar el ciclo de vida de los servicios
ITIL se basa en un ciclo de vida de servicios. Definiremos de manera precisa qué es un

servicio, pero ya puedo adelantar que se trata de una solución que permite generar valor añadido
para el cliente. Vamos a proponer un servicio, por ejemplo el de correo electrónico, y lo vamos a
gestionar durante todo su ciclo de vida. Este ciclo de vida tendrá cinco etapas principales, cada una
de ellas depende de la otra y, si la primera falla, la segunda también, la tercera aún peor y la
última será una catástrofe. Por ello hay que tomarse tiempo de incorporar un máximo de recursos
en cada una de las etapas diferentes y sobre todo en las etapas primarias de la puesta en marcha
de los servicios. La primera etapa de los servicios se trata de definir la estrategia de la
organización. Detallaremos de qué se trata con precisión, pero ya te digo que se trata de un marco
a alto nivel de lo que es la empresa, los clientes o usuarios de la misma o de la organización e
incluye las restricciones físicas, geográficas, legales, presupuestarias, etc. A partir de ese
momento, podrás comenzar a fabricar servicios que respondan en la etapa de concepción a las
necesidades de lo que los usuarios esperan de la empresa. Por lo tanto, esta etapa de concepción
es una etapa de arquitectura. A continuación, pondrás en producción estos servicios a través de
una transición, que es la tercera etapa. Esta transición es la construcción y producción de nuestros
servicios. Le seguirá la etapa de operación en la que vas a administrar, gestionar cada día los
servicios y mejorarlos, responder a los incidentes y corregir problemas. Al final, solo quedará
mejorar continuamente los servicios, que es la última etapa en ITIL, para intentar siempre ser el
más eficaz y el más eficiente al mejor coste. Así, la idea es siempre estar en el camino de la mejora
sin tregua. Esta etapa del ciclo de vida es extremadamente importante. ¿Por qué? Porque vemos
que en las empresas se busca gastar muy poco tiempo, energía y dinero en la fase de estrategia y
concepción, con lo que se hacen muchos gastos inútiles en las partes de transición y
operación. Por ello, la gestión del ciclo de servicio nos permite tener una metodología completa
para poder diseñar, concebir, poner en marcha, seguir y mejorar siempre de manera más
proactiva y más rentable los servicios que ponemos a disposición de nuestros clientes.
Alinear empresa e IT
El objetivo final de ITIL no está pensado para que el informático se divierta. Si empleamos ITIL
exclusivamente entre personas del mismo entorno, por ejemplo gente del mundo de la
informática, en general, todos ellos estarán de acuerdo para hacer un buen trabajo empleando un
mismo vocabulario con el que se entenderán y globalmente ITIL no servirá de mucho. ITIL se
centra más en las necesidades empresariales. Así, ITIL le pide al entorno informático que se
interese y entienda el cómo funciona el mundo de sus futuros clientes y usuarios. Este punto es
extremadamente importante ya que eres tú el que tiene que ir hacia el negocio y no al revés. Sin
embargo, puesto que entre la empresa, el mundo de los negocios e IT vamos a compartir un
idioma, vamos a necesitar los dos algunas nociones de ITIL, en particular los que vienen del mundo
de la empresa. De ahí el interés que tienen estos últimos en ver este vídeo y aprender así
ciertas nociones de ITIL. Si el entorno informático es incapaz de expresar correctamente unas
expectativas específicas, resultará muy difícil poner en marcha servicios que se correspondan
perfectamente con las necesidades de la empresa. A esto lo llamamos "alineamiento" y es que
este gesto es importante. Verás que en ITIL intentamos siempre alinear el entorno de IT con el
mundo de la empresa. La empresa va a cambiar, a crecer, por lo que también haremos que el
entorno IT crezca con él. Por ejemplo, llegará un momento en el que tendrás que entender el
funcionamiento de una fábrica agroalimentaria, el funcionamiento de la gran distribución, de un
entorno militar, de una administración fiscal, de todo otro tipo de organización o empresa para
poder proporcionar unos servicios diseñados para ellos específicos y que corresponden
exactamente al alineamiento de sus necesidades. De ahí el interés de utilizar este método que es
extremadamente flexible. Así entenderás que esta fase de análisis es continua porque el negocio
evoluciona permanentemente. El entorno IT tendrá que ser muy flexible, adaptarse
constantemente y estar siempre al tanto de lo que ocurre en la empresa.
Cuando la empresa y IT hablan la misma lengua
ITIL es una metodología que necesitará un lenguaje común para la empresa y el entorno IT para
que no haya malentendidos entre ellos. Lo necesitará obligatoriamente, porque es un factor crítico
de éxito que este lenguaje común defina las cosas de igual manera y que todo el mundo, cuando
hablamos de un servicio, cuando hablamos de un cliente o de un compromiso de servicios,
comprenda exactamente de qué se trata y cuáles son las expectativas. Si no, caemos en los
metalenguajes comerciales que, de hecho, no quieren decir nada especial, aparte de que el
comercial intentará tener un lenguaje que le beneficie más a él que al cliente. Cuando trabajemos
en ITIL, cada palabra tiene un significado muy preciso que todos los interlocutores deben
conocer. Es extremadamente importante. Insisto de verdad en este factor crítico de éxito. Son
palabras corrientes que estás acostumbrado a escuchar fuera de este contexto en el que no tienen
el mismo significado: la palabra "valor", la palabra "servicio", la palabra "problema", la palabra
"incidente" y la palabra "acontecimiento". Sin embargo, en ITIL han de tener una
definición extremadamente estricta y me permito insistir mucho en ello.
Mejorar continuamente el ciclo de vida ITIL
ITIL se basa en un cierto número de principios y entre estos principios fundacionales está la Rueda
de Deming. Deming es un universitario que fabricó una metodología de mejora constante que, de
hecho, nos encontramos muy a menudo en las metodologías de gestión de proyectos. Se trata de
una rueda de mejora continua que sube una cuesta y que avanza siempre hacia una mayor calidad
y siempre a un coste menor y con el menor número de riesgos posibles. Para ello tenemos que
empezar siempre tomando una medida de partida que llamaremos "línea de base" o "baseline". A
continuación, vamos a planear y mejorar considerablemente nuestros servicios a través de un
principio que se llama PDCA: Plan, Do, Check y Act. El principio PDCA es esencialmente de
acumulación a lo largo del ciclo de vida de los servicios y añade un número importante de
conocimientos. Hablaremos de gestión de conocimiento, o "knowledge management" en
inglés, que nos permitirá extraer datos de forma que podremos realizar tareas de "business
inteligence" para decir "Aquí sería interesante mejorar este o aquel proceso" o "Aquí sería
interesante mejorar esto o aquello". Respecto al coste, si la mejora vale la pena, veremos un
mayor valor para un coste cada vez menor. Y la Rueda de Deming, además de la mejora de la
calidad y la de costes, busca siempre la mejora en la rapidez de adaptación, lo que te permitirá
siempre un buen alineamiento con las necesidades de la empresa.
Descubrir al cliente
En el marco de ITIL vamos a trabajar bajo el modo cliente/proveedor. El cliente se definirá en ITIL

como una persona o grupo de personas que está autorizado a negociar la compra de uno o varios
servicios con el departamento de IT de la empresa. Es este cliente el que va a definir todas las
funcionalidades que espera del servicio informático en cuestión y que va a definir todas las
expectativas, además de las funcionales, relativas a la disponibilidad, la seguridad, la
continuidad de la actividad y de todo el resto de parámetros. Por ejemplo, un cliente va a decir:
"Quiero poder enviar y recibir correo electrónico". Entonces le dirás: "¿Quieres enviarlo las 24
horas del día, los 7 días de la semana o solo cuando estás en la oficina? ¿Quieres que se guarden
los correos electrónicos por un período de tiempo? ¿Quieres que tengan firma digital? ¿Quieres
que se utilicen en otros procesos del negocio? ¿Quieres usarlos para confirmar los pedidos?". Y así
otras características relativas al uso del correo electrónico. Así, el cliente va a definir todas las
necesidades que tiene en su actividad empresarial y todas las obligaciones que va a tener el
proveedor de servicio. Es el cliente el que tendrá que financiar el servicio y dar y pedir cuentas a la
Dirección y a IT sobre la caída de los servicios prestados con respecto a la petición que se le hizo.
Examinar al proveedor del servicio
Entendemos por "proveedor del servicio" el servicio informático de una empresa u

organización. Así, la mayor parte del tiempo hablaremos de servicio informático interno de una
empresa. Incluso si se trata del servicio informático interno de una empresa, esta en las relaciones
que tiene con la empresa debe considerarse como una sociedad de servicio informático. Por ello,
debe poner en marcha una práctica de tarificación para evitar pérdidas económicas. Se trata de
poder producir valor y al menos, si no se gana dinero, la idea es que no se pierda tampoco. El
proveedor del servicio será responsable de la entrega del servicio que pide el cliente y, sobre todo,
de su concepción desde un punto de vista técnico y a continuación de su mantenimiento
operacional. El cliente, una vez que se pone de acuerdo con el proveedor, ya no tiene que
preocuparse ni de los aspectos técnicos ni de los financieros. Ha negociado un servicio con un
cierto número de parámetros que incluyen una compensación económica por esos servicios y el
proveedor del servicio tiene que proporcionarlos conforme a los compromisos que han adquirido
por escrito. Este es el papel del proveedor de servicio en ITIL. Incluso cuando el proveedor del
servicio es un departamento interno de la empresa, intentará funcionar como una empresa
independiente por una razón muy simple: es lo que te permitirá después refacturar los servicios a
las diferentes entidades asociadas, a la empresa o sus divisiones. Por ejemplo, pongamos que a
final de año la inversión en informática ha costado 100 000 euros en "hardware". En un primer
momento se va a cuestionar el excesivo gasto en esta inversión. Llegados a este punto, si trabajas
en modo ITIL, dirás: "No, la informática no ha gastado 100 000 euros de "hardware", sino que ha
instalado al departamento de Marketing 10 000 euros de "hardware", 20 000 euros al
departamento de Contabilidad y al de Dirección otros miles de euros". Y entonces es cuando
hacemos una refacturación en interno. Esto hace que en ITIL sabemos quién consume qué, y ya no
es el presupuesto de informática, sino el consumo individual, es decir, ya sea de clientes o de los
diferentes servicios o departamentos concretos y de los usuarios de estos servicios dentro de la
empresa o la organización.
Definir el proveedor externo
Los proveedores externos son en ITIL las personas con las que vas a firmar subcontratos. Estos
contratos se llaman UC que significa en inglés "underpinning contract". Se trata de contratos que
se adjuntan y que serán parte de tu servicio. Por ejemplo, imagina que propones el servicio de
mensajería instantánea a tu cliente. Puedes estar obligado a recurrir a un cierto número de
subcontratistas, sobre todo alguno que te proporcione el soporte necesario en cuanto a servidores
y accesibilidad a través de Internet. Para el cliente final todo esto es transparente. Compra un
servicio y los contratos que firmas con un proveedor externo son parte del servicio y no necesita ni
siquiera conocer su existencia. Así, los proveedores externos se gestionan como componentes de
un servicio. Más específicamente, lo que llamamos los UC, los "underpinning contracts" van a ser
elementos de servicio. Un servicio, como veremos, se compondrá de todo tipo de elementos: los
inmateriales, los materiales, "software" y los procesos. En este puzle podríamos llegar a un punto
en el que estableceremos que quiero tener subcontratos y los tendré asociados a servicios que no
puedo ofrecer directamente o como parte de servicios que sí puedo ofrecer pero para los que
no dispongo de la infraestructura necesaria para el total del servicio.
Detallar el servicio
Un servicio es un conjunto en ITIL de diferentes componentes que sumados se destinan a proveer

valor a nuestro cliente final. El valor, lo veremos, se determina a través de la utilidad y la
garantía. Trabajamos en ITIL haciendo la gestión de un ciclo de vida de servicio. Este último
comienza por la estrategia, sigue con la concepción, la transición, la operación y la mejora
continua del servicio. El servicio de ensamblado de los diferentes componentes, materiales,
"software", personas, procesos y socios externos se verá como una sola entidad por el cliente final,
con independencia de su complejidad. El servicio se destina a facilitar el trabajo de la empresa. Es
decir, cada vez que pones en marcha un nuevo servicio informático, tienes que reflexionar. El
objetivo es siempre ofrecer al cliente la posibilidad a través del servicio de que obtenga, por
ejemplo, una mayor cuota de mercado, una reducción de costes en la fabricación o, en general,
cualquier ventaja competitiva que le permita sobrepasar a la competencia y esto, claro, habrá que
demostrarlo. El encargado de demostrar que el nuevo servicio aporta este valor real es a la vez el
servicio informático que lo va a concebir pero también es el cliente quien lo pide. Esto evitará algo
que se ve muy a menudo, esos "software" extraordinarios que solicitan los clientes que caen en el
olvido de muchas empresas y que nunca serán utilizados porque, por la utilidad y valor añadido
real que podrían aportar al negocio, nunca se realiza como se había previsto o no se ha
reflexionado lo suficiente en ello.
Tener nociones sobre el usuario
En ITIL los usuarios designan a los encargados de usar los servicios cada día. Estos pueden ser los
clientes, por ejemplo. Pero los clientes también pueden pedir servicios para los usuarios y no
ocuparse de ellos o no utilizarlos ellos mismos. Distinguiremos dos tipos de usuarios: los usuarios
internos o empleados en empresas, los que propondremos un cierto número de servicios, y los
usuarios externos que son personas como tú y como yo, que accedemos al producto final de la
empresa a los que se ofrece otro tipo de servicio. Por supuesto, ITIL te recomendará
encarecidamente que preguntes a los usuarios que utilizan los productos y servicios cada día que
intentes adivinar sus expectativas. Del mismo modo, ITIL de manera inteligente en una
etapa específica del ciclo de vida dirá: "Atención. Estás poniendo en marcha un nuevo
servicio. ¿Quieres que el valor añadido esté presente? No olvides informar a los usuarios finales y
formar a los equipos de soporte técnico". Así, el usuario planteará muchas preguntas y
nosotros también nos preguntaremos acerca de su confort, del uso futuro que hará de los
servicios para estar seguros de que no dejamos de lado sus necesidades y que el valor añadido
está a la altura de nuestra servicio.
Apoyarse en el nivel de servicios OLA
Se puede firmar otro tipo de compromiso particular. A eso lo llamamos "nivel de compromiso
operacional" (Operational Level Agreement) al que le damos el acrónimo inglés que denominamos
"OLA". Este OLA transforma al servicio informático a partir de ese momento en cliente de
proveedor interno. Este proveedor interno podrá ser, por ejemplo, la gente de Recursos
Humanos. Si tienes que entregarle las nóminas el 25 de cada mes, es obligatorio que los elementos
contables se transmitan al servicio informático el 24 de cada mes o antes. Así, firmarás con
recursos humanos un OLA por el que deberán entregar los datos en un formato concreto, en una
fecha específica, según las modalidades que decidas... Es decir, un compromiso de servicio
particular para que puedas tener un OLA del servicio de creación de nóminas el 25 de cada mes,
por ejemplo.
Interesarse por el nivel de servicio

El "nivel de servicio" es un concepto fundamental en ITIL. Hablaremos de "compromiso de nivel de
servicios" en español, pero la mayor parte del tiempo escucharás el término inglés Service Level
Agreement y su acrónimo, SLA. Cuando hablemos de SLA, hablaremos de negociación y de un
documento que incluye, entre el cliente y el proveedor de servicios, lo que se espera por ambas
partes. Este documento extremadamente formal nos va a decir qué servicio hay que hacer, qué
debe garantizar, cuáles son los contactos para el mismo y, por lo tanto, todos los aspectos que
conciernen a la tarificación: los técnicos, los de disponibilidad, los de funcionalidad, los de
seguridad y los de soporte. Es decir, todo lo necesario para cualificar este servicio. A partir del
momento en el que hayamos definido este conjunto de medidas, podremos medir. Recuerda que
solo podemos gestionar lo que podemos medir. En el momento de definir los SLA, cuidaremos la
definición de las herramientas y las métricas que se utilizarán para medir. Y a partir de ahí, del
momento en el que el servicio se ponga en producción, vigilaremos los diferentes contadores y
podremos decir "Efectivamente, yo como proveedor de servicio, he alcanzado los niveles
de servicio que me han pedido" o "No he alcanzado los niveles de servicio que me piden". Esto te
permitirá poner en marcha rápidamente las acciones correctoras. No hay buenos o malos
servicios. No hay servicios bien o mal hechos. Simplemente, hay servicios que están
perfectamente adecuados al SLA firmado o no lo están. Y fíjate, el SLA también es la alineación de
lo que pide la empresa. Recuérdalo siempre: "En ITIL, yo me alineo siempre con lo que pide la
empresa". Estos SLA se negocian con el cliente, sobre todo en lo referente a los precios. El cliente
dice: "Quiero una disponibilidad del 100%". En general, cuando le comunicas el precio que
supone, dice: "No. Finalmente, quizás solo al 80% me llega y me sobra". Le reajustas el precio y
entonces se establece una negociación permanente y, después, una mejora continua
permanente. Atención: en ITIL, si sobrepasas tu SLA, si te dicen por ejemplo "Necesito una
disponibilidad del 50%" y subes al 80-90%, te equivocas. ¿Por qué? Porque no te has ceñido a lo
que te pedía la empresa. Mejor estar en el 49% que en el 80%. ¿Por qué? Porque, en ese caso,
quiere decir que has utilizado demasiados medios y entramos en pérdidas. Efectivamente, cuando
tenemos medios ilimitados, tener SLA muy elevados es complicado. Sin embargo, lo que se te pide
es alcanzar el SLA que corresponda con las necesidades reales de la empresa y en relación con los
SLA que se han definido y pedido por la empresa. Un ejemplo muy rápido: un "software" de
nóminas debe funcionar una vez al mes para hacer los pagos. Perfecto. Es decir, este "software"
funcionará solo dos días al mes. Si tiene una disponibilidad del 100%, gastaré electricidad, tiempo,
red, potencia de cálculo… para nada. Y entonces pierdo valor añadido, porque gasto tiempo
o dinero y recursos para nada. Esta es una idea de lo que son los SLA. El SLA se crea y diseña junto
con otras partes interesadas, sobre todo, proveedores externos. Con un proveedor externo firmas
un "underpinning contract", que también es un SLA. Sin embargo, el proveedor externo lo que
firma es un SLA porque él es el proveedor y tú el cliente. Te pido que tengas cuidado con ese
término, SLA, sobre todo en la gestión de los proveedores. ¿Por qué? Porque muchos proveedores
tienen términos completamente impropios o de andar por casa. Oirás hablar de GTR, Garantía de
Tiempo de Restablecimiento, que no quiere decir nada y que no corresponde con lo que nosotros
llamamos SLA. Por ello, vigila e intenta tener siempre interlocutores que hablen tu misma lengua,
porque el día que te encuentres un problema te dirá: "No, mira, el contrato estaba de esta o de tal
manera", y tratará de no hacerse cargo de las responsabilidades asociadas al mismo. Así que ten
cuidado. Habla siempre de SLA con tus interlocutores, ya sean de tu mismo ámbito profesional
o de proveedores externos.
Concentrarse en el valor
El valor en ITIL es el elemento principal. Se puede traducir en términos monetarios de tiempo o de
diferentes formas, pero siempre tiene que ser medible. Por ejemplo, decir "Mejoré el confort de
experiencia de uso de los usuarios" no es valor. El valor se definirá con dos parámetros, los
explicamos a continuación, que son la utilidad y la garantía. Todos los servicios que propones, e
insisto mucho en ello, todo servicio propuesto por un cliente y proporcionado por el servicio
informático debe obligatoriamente generar valor y tiene que estar en condiciones de poder probar
ese valor añadido. Así se elimina lo que denominamos "modo capricho" en las empresas, donde
tienes, por ejemplo, un grupo de personas que van a exigir un "software" particular o un modelo
de teléfono particular o accesos particulares, que no siempre necesitan, a la fuerza o que ya
tienen establecidos de otra forma, y que solo quieren como "gadget" o por elemento de lujo. En
esos casos es extremadamente sencillo en ITIL poder demostrar que ofrecer el último "gadget" no
dará ningún valor añadido específico a la empresa y que incluso puede comprometer el valor
añadido, generando por ejemplo, una brecha en seguridad o un sobrecoste innecesario. Así, esta
noción de valor añadido siempre tiene que estar en tu cabeza. Del mismo modo que una empresa
debe generar valor, si por ejemplo, es una empresa agroalimentaria, de vender todo el producto
posible y tener margen, del mismo modo todo lo que fabricas debe ayudar a esta empresa, en
términos de servicio informático, a vender más producto y de mayor calidad, con un mejor control
y ganándole mercado a la competencia. Entonces esta noción de valor es verdaderamente
fundamental y debe estar en el centro de todas tus reflexiones sobre la creación de nuevos
servicios. Y así verás que hay empresas en las que la tecnología es un "gadget", mientras que en
otras será fundamental para dar valor. Cuando queramos rechazar un servicio particular a un
cliente, podremos decirle que no somos capaces de calcularlo o demostrar el valor que tendría el
servicio solicitado. Si puedes demostrarlo, no plantea problema. Si no eres capaz, hay muchas
posibilidades de que este valor no exista. Esto se traduce en tiempo o en dinero incluso en las
sociedades o las organizaciones no comerciales, por ejemplo, en un ayuntamiento o en una
organización sin ánimo de lucro.
Centrarse en la utilidad
El valor se define mediante dos parámetros: el primer parámetro es la utilidad, y el siguiente, que
veremos más tarde, la garantía. ¿Qué es la utilidad? La utilidad es poder demostrar que el servicio
produce el resultado esperado. Hemos solicitado un servicio que, por ejemplo, crea las nóminas a
final de mes. Es decir, a finales de mes tienen que tener disponibles las nóminas. Esta es la
utilidad. Si, por ejemplo, salen hojas en blanco o si la mayoría de las impresiones son de mala
calidad, ilegibles o erróneas, e incluso están mal colocadas en la página, la utilidad de la hoja de la
nómina no se garantizará realmente. Entonces, si no hay utilidad, automáticamente no sé habrá
generado valor. Así, hay que concentrarse, lógicamente, en el aspecto funcional del servicio. Si
vendes el servicio envío-recepción de mensajes, es importante que todos los mensajes que salen
y llegan lo hagan correctamente, y que yo pueda enviar y recibir los mensajes. Este es entonces un
aspecto funcional en el que me tengo que concentrar. Por supuesto, la utilidad se ha definido en el
documento SLA, que ha determinado de manera muy precisa lo que esperamos en términos de
utilidad de un determinado servicio. La mayor parte del tiempo, es el cliente el que va a
definir exactamente sus expectativas, porque él está en el negocio y, por lo tanto, la utilidad. Así,
incluso te dirá: "Mira, esta es la hoja de nómina tal como debe ser", y entonces te definirá con la
mayor precisión la utilidad, el cumplimiento o no de esta utilidad, con las herramientas de
medida y las métricas asociadas.
Abordar la garantía
Tras la utilidad, para estar seguro de que proporciono valor, necesito entregar una garantía. La
garantía consiste en respetar un cierto número de parámetros, que son el rendimiento, la
seguridad, la disponibilidad, la integridad, y dar un buen servicio a la persona correspondiente
justo en el momento y lugar adecuados. Imagina que solo se imprime la mitad de las hojas de
nómina, que se imprimen ocho días más tarde o que se imprimen y envían a quien no
corresponde, por ejemplo. Imagina que mi servicio de "email" funciona, que puedo enviar y recibir
correos electrónicos pero, por ejemplo, no tengo tratamiento antivirus. En la mayoría de los
correos electrónicos que recibo hay virus o "spam", o cuando le envío un "email" a alguien, llega
cuatro horas más tarde en vez de ser casi instantáneo. A esto le llamamos "garantía". La garantía
es tan esencial como la utilidad. Si tengo la garantía de un rendimiento excepcional y de seguridad
pero no tengo la utilidad, no creo valor, y lo mismo al revés. Entonces, la creación de valor pasará
por esta doble competencia: garantía más utilidad. En nuestro SLA tenemos que definir
obligatoriamente lo que esperamos a nivel de garantías y ser muy precisos. Del mismo modo,
tendremos que definir las medidas y objetivos que hay que alcanzar y cómo medirlos, así como
unas buenas métricas. Esto será parte de lo que tenemos que vigilar en la producción y puesta a
disposición, e incluso desde la concepción de nuestro servicio.
Comprender el proceso
Trabajar con el método ITIL impondrá para algunos una nueva disciplina, que es la gestión de
procesos. ¿De qué se trata la gestión de procesos? Para todo lo que se producirá o hará la
empresa, desde una acción informática o de producción de bienes o servicios, o incluso una parte
de la producción de bienes o servicios, se tratará de asignar sistemáticamente a un
procedimiento bien controlado. Puedo reemplazar la palabra "proceso" por "procedimiento" o
incluso por "protocolo". También la puedo reemplazar por "algoritmo" si trabajas en el mundo
industrial. Es algo que te resultará muy familiar. Por ejemplo, para fabricar un coche o para
fabricar comida, habrá que seguir de manera muy precisa un conjunto de procedimientos, unos
tras otros, y sobre todo, hay que tener en cuenta que solo sabremos gestionar los errores si se
sitúan tras un control. Y solo así descubriremos si vamos a tener que tirar una pieza o rehacerla,
por ejemplo. Esto implica las nociones de "trazabilidad" y de "control". Haremos exactamente lo
mismo para la gestión de nuestros servicios informáticos. En cuanto a la gestión IT, por ejemplo,
renovar una contraseña, poner en marcha una nueva impresora o crear un nuevo usuario, tendrás
que escribir o describir el proceso exacto que habrá que seguir para poder realizar esta
acción. Esto hace que cualquier persona que venga a la empresa solo tenga que retomar los
procedimientos para poder explotarlos. La idea es tener una calidad siempre controlada. De
hecho, salimos de un modo artesanal, que puede tener una calidad extraordinaria pero que
es difícilmente reproducible, para ir a un modo industrial con una calidad que se ha negociado con
antelación y que se controla estrictamente. Se trazará y se controlará cada acción. Habrás
adivinado que caemos un poco en las normas ISO, y es que ITIL se inspira mucho en ellas en lo
relativo al conjunto de procedimientos. Pero también tendrás que pedir a tus clientes que
describan todos sus procesos empresariales. Para fabricar un servicio informático necesitas
material, "software", personas, posiblemente otros servicios externalizados, contratos
internos, pero también necesitas todos los procesos empresariales asociados al servicio. No
obstante, para algunas actividades será mucho más complejo. Imagínate un bufete de
abogados. Es extremadamente difícil para un abogado explicar su trabajo en términos de
procesos. Sin embargo, hay que ir hasta el final de lo que se puede definir en esos términos. La
idea es que, una vez que el proceso está bien establecido, puedes descubrir qué parte del proceso
se puede realizar con una solución informática, y entonces automatizarla y permitir ganar tiempo,
dinero y generar valor. Esta es la idea de procesos que nos encontramos durante todo el ciclo de
vida ITIL.
Definir el objetivo de la estrategia
La estrategia de servicio es el comienzo que desencadenará el resto de elementos del ciclo de vida
de los servicios. Es una etapa fundamental en la que hay que insistir. ¿Por qué? Porque, con
frecuencia, en las organizaciones, o existe una estrategia pero no se le asocia la informática o no
existe ninguna estrategia en absoluto. ¿Qué es la estrategia? Se trata de cuadrar a alto nivel los
límites y los campos de acción de los diferentes servicios que tendrás para proponer. De hecho, se
trata de preguntas muy simples: ¿Quién soy? Es decir, ¿cuál es mi empresa? ¿A qué se dedica
específicamente? ¿Cuál es su cifra de negocio? ¿Cuál es su presupuesto y su presupuesto
informático? ¿Cuál es su lugar frente a la competencia? ¿Qué tecnologías emplea? ¿Es la misma
tecnología que la de la competencia? ¿Cuáles son sus obligaciones legales? ¿Cuál es su
implementación geográfica? ¿Tengo mucho personal itinerante? ¿Soy subcontratista? ¿Tengo
muchas empresas socias que trabajarán conmigo? ¿Mi mercado es vertical? ¿Mi mercado es
horizontal? ¿Estoy dispuesto a adquirir en seis meses, dos años, cinco años, otras
empresas? ¿Quiero comprarme a mí mismo? Todos estos elementos participan de la estrategia y
es extremadamente importante que se anoten en su integralidad y que la informática se le
asocie. Voy a darte un ejemplo de un caso donde la informática se asocia de manera sistemática a
la estrategia. Ya sabes que esta se decide en el nivel más alto de la empresa. Y en las empresas
informáticas se considera, digamos, un peso muerto entre comillas y no se asocia realmente a las
decisiones. Por el contrario, si trabajas en el mundo de la banca, esta asocia de manera sistemática
todas las decisiones a la gestión informática. No es porque la gente de banca tenga ganas de hacer
ITIL. De hecho, ya lo hacían antes de que apareciese. Es simplemente que son plenamente
conscientes de que, si la informática no da los servicios adecuados, no podrán hacer su propio
trabajo y entonces ganar dinero. Así, cuando el departamento informático dice "Sí", en ese
momento la dirección puede avanzar como quiere. Si el departamento informático dice: "Espera,
ahora no es buen momento", "La tecnología está cambiando" o incluso "No tenemos el
presupuesto necesario" o "Corremos el riesgo de no cumplir un cierto número de reglas o leyes
nacionales o internacionales", en este momento la gente de banca se parará. Es decir, la dirección
del departamento de informática se implica de verdad en la dirección general. Por desgracia, lo
que vemos con frecuencia en las empresas es que el departamento informático es el último al que
se informa. Se le dice: "Mira, acabamos de comprar una empresa en China y habrá que integrarla
en el grupo". Y esto te lo cuentan dos meses antes. Así que, lógicamente, dos meses antes ya te
imaginas que no podrás concebir unos servicios de calidad extraordinaria. Si se conciben mal los
servicios, se instalarán mal, se explotarán mal, y entonces se inicia un círculo vicioso en lugar de
uno virtuoso. Esta etapa de estrategia y la costumbre que debería adquirir la Dirección de la
empresa de comunicarse con el departamento de Informática para poder preparar los mejores
servicios con antelación y, sobre todo, para el presupuesto, debería ser verdaderamente un
objetivo principal de tu implementación ITIL. A menudo la gente se pregunta por dónde empezar y
la clave es implementar una estrategia, solicitar tiempo a Dirección y que expongan claramente los
proyectos futuros de aquí a seis, 12, 24, 36, 72 meses, para poder tener una idea general. Esto
implica un cierto nivel de confianza pero también que la Dirección entienda realmente el valor
añadido que le das a la empresa, incluso si el trabajo que tiene es fabricar productos de
alimentación y que no tiene mucho que ver con el departamento de Informática. Si la informática
no acompaña el proceso, te costará más salir adelante que alguien de la competencia que tiene
una buena herramienta informática para poder ayudarle. Se trata de una gestión que lleva tiempo
y que exige mucha madurez a tu organización. Muchas veces lo difícil no es conseguir dinero en la
empresa, sino tiempo de sus dirigentes. Esto es lo que puede causar problemas. A partir del
momento en el que se ha definido el marco general de la estrategia, podrás canalizar la petición
de nuevos servicios en eso que denominamos "gestión de la demanda". Podrás actualizar
constantemente esta estrategia. ¿Por qué? Porque la estrategia va a evolucionar con las
tecnologías, con los negocios, las compras, las implantaciones en otros países o implantando otros
parámetros, y así estará en constante movimiento. Entonces tendremos que realinear siempre la
informática con la estrategia. Por ejemplo, en la estrategia gestionaremos también los riesgos. Es
lo que hemos intentado obtener, lo que debemos buscar y hacia donde debemos apuntar. Es lo
que llamamos una "buena gobernanza". Una "buena gobernanza" es una palabra que se usa
mucho actualmente, pero en ITIL quiere decir algo muy simple. Una buena gobernanza es un
alineamiento perfecto entre lo que pongo en marcha en IT y lo que me pide el negocio, y que esté
listo para evolucionar muy rápidamente en caso de nuevas solicitudes y necesidades. Así, esto
implica también un cambio de mentalidad en la empresa y que los gestores de cualquier
nivel, fuera de la informática, pasen tiempo interesándose por este método, con el que
también saldrán ganando. Todo el mundo saldrá ganando con el uso de ITIL.
Evaluar el subproceso de la estrategia

El servicio de estrategia va a englobar un cierto número de subprocesos. Vamos a enumerarlos y a
describirlos brevemente. Para empezar, la "gestión del portafolio". ¿Qué es el portafolio? Se trata
de la lista de todas las solicitudes de nuevos servicios que te piden los clientes. Y así estudiaremos
la viabilidad, su urgencia o la aprobación, es decir, si se lanza o no tal iniciativa. Una segunda parte
de este portafolio es lo que llamamos "catálogo de servicios". Se trata de todos los servicios que
están actualmente en producción y todos los que están a punto de entrar en fase de
producción. Esta parte se gestionará en otra etapa del ciclo de vida del servicio. Por último, en el
portafolio encontraremos la lista de todos los servicios que se han retirado. Un segundo aspecto
es el de la "gestión financiera": ¿Qué presupuesto tengo? ¿Cómo lo voy a negociar? Como soy una
SSII, o servicio de información, habrá que asegurar el presupuesto, aunque sea un servicio de
información interno. Para poder determinar el valor de los servicios, es obligatorio saber cuánto
cuesta porque el valor, por supuesto, ha de ser más importante que el coste del servicio. Esto es
muy evidente pero aun así hay que recalcarlo. Así que vamos a determinar el coste de cada uno de
mis servicios. También determinaremos los métodos de facturación, por ejemplo, si lo hago por
usuario o por servicio, para poder proporcionar una contabilidad analítica, gestión financiera,
gestión del portafolio y gestión de la demanda. Así recibiremos todas las solicitudes de nuevos
servicios. Por otra parte, la "gestión de riesgos" es algo extremadamente importante: ¿Cuáles son
los riesgos a los que me enfrento por tal o cual servicio? ¿Cuáles son los riesgos de mi tipo de
empresa y de actividad que no se pueden permitir? Si soy, por ejemplo, un centro de incendios y
socorro, no me puedo permitir tener una informática y telecomunicaciones que se estropeen con
frecuencia, por lo que obligatoriamente tendré que adoptar medidas específicas. Por el contrario,
si soy, pongamos, una pequeña asociación que gestiona un club de canoas, podríamos estimar
que, si por ejemplo tengo un corte informático, quizá las consecuencias serían menores. Todo esto
se gestiona al nivel de los riesgos. Gestionaremos, por supuesto, el riesgo legal, es decir, el que me
imponen las leyes y los reglamentos del país en que estoy, los países con los que voy o no voy a
trabajar. Estas serán algunas de las misiones secundarias que tendremos que desarrollar en la
etapa del ciclo de vida estratégico. Al final, tendremos muchas preguntas y reuniones, y eso se
puede gestionar con los proyectos. No plantea problemas particulares y es aconsejable porque lo
más complicado es obtener tiempo de la dirección, que siempre es más propensa a decirte: "No
tengo tiempo para esto". Pero hay que entender que este tiempo será extremadamente rentable
en el futuro. En general, en las empresas pasan muy poco tiempo con la estrategia y su
concepción y, sin embargo, pasamos muchísimo tiempo con su explotación. El objetivo en ITIL es
el contrario: destinar a la informática el máximo de tareas con poco valor añadido para poder
automatizarlas y que así se creen estrategias, concepción y mejoras constantes. Entonces tanto los
informáticos como los clientes salen ganando porque tienen el nivel de servicio que han pedido y
que los compromete por contrato.
Comprender el objetivo de la concepción
La creación o concepción de servicios es la segunda etapa del ciclo de vida que no tiene ningún
sentido si la primera no se ha realizado correctamente. Se trata de la estrategia que va a decir
en la gestión de la demanda, efectivamente, doy luz verde para lanzar la creación de este
servicio. Esta etapa de creación va a producir toda la documentación necesaria y es un trabajo de
arquitectura para crear el servicio para, a continuación, poder administrarlo, medirlo, gestionarlo
diariamente y así unir virtualmente todos los diferentes componentes que van a constituir el
servicio. Para poder concebir un servicio, necesitamos cuatro elementos a los que denominaremos
"4P", por los términos en inglés. Para fabricar un servicio, necesito un Process, es decir, un
proceso. Necesito People o personas, un equipo compuesto de personas del mundo de la
empresa, pero también del mundo de la informática. También necesito "partenaires", ya sean
"underpinning contract" o consultores externos. Y finalmente, necesito Product o producto. En el
99 % de casos, cuando no aplicamos el buen sentido ITIL, todo el mundo se centra en una cosa:
Product. El "product" es lo último en lo que deberíamos pensar normalmente. Hay clientes que
solicitan, por ejemplo: "Quiero un servicio de mensajería 'exchange'". Pues bien, lo primero que
deberían pedir es: "Quiero un servicio de mensajería que pueda tener esta o aquella característica,
que pueda hacer esto o lo otro, con esta garantía y esta utilidad". A continuación, vemos todos los
procesos empresariales que se asocian. Por ejemplo, esto podría corresponder con los pedidos, los
momentos en que se contacta de nuevo con los clientes o la gestión de un CRM, y solo después
veremos si hay personas ya en la empresa que puedan gestionar esta solución. A continuación
podremos acudir a subcontratistas, y, por último, nos interesamos en los diferentes productos que
debemos comprar o no. A veces tenemos en la empresa productos que no se usan y que podrían
hacer lo que se pide. Ocurre a menudo que puedes encontrar duplicados o triplicados de compras
de servicios u otros elementos en el interior de una empresa. Entonces en esta etapa de creación
utilizaremos bien estas 4P. Y sobre todo, no empezamos por la parte producto, que es lo más
complicado y lo más difícil que se le pide a la empresa. Es decir, hazme procedimientos sobre lo
que es tu actividad. Esto a menudo es muy difícil, salvo si trabajas con procesos de facturación, de
cobro, procesos de pago, procesos definidos de manufactura, etc. Pero en otras profesiones es
más complicado. Lo ideal es trabajar en el mundo industrial, donde ya tenemos una cultura de
procesos, que es donde no se plantea ningún problema en absoluto. Entonces empiezas por los
procesos y después todo el resto hasta los productos, que son las cosas en las que pensamos en el
último lugar. Concéntrate en los procesos. ¿Por qué? Esto es lo que hace que la empresa sea
única. La empresa X o Y, que tienen la misma actividad, tendrán procesos diferentes siempre. Esto
es lo que constituye la cultura empresarial. Tienes como consultor ITIL o como parte de la
empresa la obligación de ayudarles, pero son ellos los que conocen mejor el oficio que tú, aunque
serás tú el que tengas que esforzarte para comprender el oficio, ya que no son ellos los que tienen
que entender la informática.
Descubrir el subproceso de la concepción
La creación o concepción se asemeja a la construcción de una casa. Para construir una casa,
necesitamos un arquitecto que va a diseñar todos los planos y que va a prever todos los elementos
necesarios, va a decir: voy a necesitar tantos kilos de cemento, tantos ladrillos, tantas estructuras
de madera, tantas tejas, tantos tubos para hacer la conducción de agua, etc., etc. En esta etapa de
concepción, vamos a hacernos todas estas preguntas y, consecuentemente, crear un buen montón
de listas. Esta es una parte de los subprocesos que impulsan la creación o concepción. En primer
lugar, vamos a hacernos preguntas sobre la coordinación de diferentes elementos. Es lo que
ocurriría con un arquitecto que va a coordinar todos los diferentes gremios. El subproceso de
coordinación se parece mucho a la gestión de proyecto, utiliza tus competencias en gestión de
proyecto. Segundo proceso: gestión de la disponibilidad. ¿Cuál es la disponibilidad que se va a
pedir para este servicio? El tercer proceso será la gestión de la seguridad. ¿Qué se le va a pedir a
este servicio en términos de seguridad? La seguridad en ITIL significa CIA. Confidenciality para
confidencialidad. Integrity para integridad y Availability para disponibilidad. Vamos a hacernos
preguntas sobre los SLA. Se negocian para cada servicio en la fase de concepción. El cliente quiere
ese servicio y va a decir: aquí están mis SLA, mis utilidades, mis garantías, lo que quiero, etc., etc.
Tú le dirás: esto no es posible, no puedo hacerlo con ese presupuesto. Entonces él te dirá: Ok,
puedo bajarlo un poco. Sí, vale. Y llegar a un equilibrio en el que ganen los dos. Un consejo para los
departamentos informáticos: no aceptéis nunca por compromiso SLA que no estéis seguros de
poder conservar. ¿Y por qué ocurre a menudo que no los puedes mantener? Porque no tienes
todas las competencias de los productos ni todos los presupuestos y, sobre todo, no tienes todo el
personal necesario. Los días solo tienen 24 horas y a veces puedes meterte en servicios que
consumen mucho tiempo de administración y esta es también una de las preguntas que hay que
plantearse en el momento de la concepción. A veces, tiene soluciones que al comprarlas son más
caras pero que, a fuerza de administrarlas, acaban siendo mucho más económicas que otras
soluciones donde pasará lo contrario. También gestionarás la parte de la seguridad. Ya lo hemos
comentado, gestionarás la parte "disponibilidad" del servicio. En caso de bloqueo del sistema,
¿tengo que seguir? ¿Durante cuánto tiempo? ¿Qué está dispuesto a aceptar mi cliente en caso de
catástrofe, como un incendio? ¿Cómo detalla su SLA y durante cuánto tiempo? Y en esos casos
prevemos planes de continuidad y de reanudación de actividad del servicio y los
documentamos. Estos son algunos de los diferentes subprocesos que responden a preguntas que
nos hacemos y hay que intentar ser lo más exhaustivo posible cuando hagamos esta fase de
concepción. La primera vez que hagas una fase de concepción, anotarás, por supuesto, todas las
preguntas que tengas. Así, en la próxima concepción de servicios tendrás una plantilla, una matriz
que solo tendrás que mejorar y rellenar. Es decir, que si la primera vez te llevó un mes, te llevará
mucho menos la segunda vez. Si la primera vez tuviste que rehacer la concepción en tres versiones
porque no era buena, la segunda la mejorarás con lo aprendido. Esto es parte de la mejora
continua. Cuando hayas terminado por completo todos los subprocesos y hayas terminado de
hacerte todas las preguntas y hayas dado todas las respuestas, producirás una documentación que
se llama Service Design Package o un SDP. Se trata entonces de un "pack" de concepción de
servicio.
Definir el objetivo de la transición
El objetivo de la transición de servicios es la construcción y preparación para producir servicios

definidos en la solicitud de estrategia que se concibe en el momento del servicio o creación o
concepción, donde hemos creado el SDP. También debemos garantizar que podemos hacer esa
transición a producción correctamente, y que tanto el valor como los SLA, tal como se han
definido, se respeten correctamente. Durante esta etapa vamos a unir, como en el ejemplo de la
construcción de la casa, todos los diferentes componentes necesarios para fabricar el
servicio. Para poder unir todos estos componentes, es muy importante que dispongas de una base
de datos que contenga todos los elementos que sirven para componer servicios. Es importante
recordarlo, puede ser "software", procesos, personas y conocimientos. Estos pueden ser
competencias particulares o patentes que habrá que almacenar en una base de datos. Esta base
de datos se denomina Configuration Management DataBase, CMDB. Cada elemento de la base se
denomina elemento CI o un Configuration Item. Un CI va a tomar todos los elementos, todos los
campos. Por ejemplo, para un ordenador, procesador, memoria, fecha de compra, tipo de tarjeta
de red, sistema de explotación, etc. Si además añado el precio que pagué por este ordenador, ya
no hablaremos de un CI, sino de Activo. Lo que se denomina Asset, en inglés. Por lo tanto, Gestión
de activos es lo mismo que Gestión de Assets. ¿Cuál es el trabajo de esta parte de
transición? Tengo una lista de componentes que se me da y, como si trabajas en un almacén, voy a
buscar en mi base de datos todos los elementos que necesito para construir mi servicio. Esto
quiere decir que una buena manera de comenzar a hacer ITIL es fabricar esta base de datos en la
que podrás almacenar los activos y/o los elementos de configuración, que te ayudará a crear una
estructura muy rápido, porque tendrás piezas referenciadas que solo tendrás que unir. Si quieres
obtener un precio, bastará añadir el coste unitario de cada una de las piezas para obtener el coste
total de tus servicios, así que este también es un buen enfoque para poder empezar a introducir
poco a poco ITIL en el interior de tu empresa. Este es, pues, el objetivo de la transición. Al final de
la misma, tendremos un servicio que ya está listo para ser operativo, que se ha aprobado, validado
y que normalmente debe responder al pliego de condiciones en término de garantía y de
características para crear el valor previsto. Si el valor previsto no está ahí, hay que volver a la
concepción porque esto querrá decir que la concepción se ha hecho mal o habrá que volver
incluso a la estrategia.
Explotar el subproceso de la transición
Como para el resto de etapas del ciclo de servicios que vamos a presentar, el servicio de
transición va a tener un cierto número de subprocesos. El primero será la coordinación de la
transición que se gestionará, lógicamente, en modo proyecto. También tendremos el proceso de
test y validación. Si, por ejemplo, la solución necesita el desarrollo de "software", en ese momento
se hará la escritura del código o la adquisición del "software" relacionado. Todo el pliego de
condiciones funcionales ya se habrá hecho durante la fase de concepción. También tendremos la
gestión de DLM, Definitive Media Library. ¿De qué se trata? Se trata de un almacenamiento
securizado en el que vamos a almacenar todas las copias maestras, así como los procedimientos
de instalación de todos los "software" que se han autorizado en la sociedad. Esto significa que
nadie más podrá instalar un "software" por sí mismo. Se prueban todos los "software" y se
conserva la versión en la que se aprobaron todos los test. Esto va a simplificar
considerablemente, después, el soporte técnico y la actualización, sobre todo de los diferentes
clientes. Tomemos el ejemplo de Acrobat Reader: imagina una empresa en la que tienes 50
versiones de Acrobat Reader. Te costará mucho más hacer de soporte técnico que con una única
versión. Entonces, cuando trabajamos en ITIL, las actualizaciones por Internet o las pequeñas
instalaciones de "software" que hacemos en ordenadores y dispositivos, sin pedir autorización, se
acaban. Esto significa, sin embargo, que si un usuario necesita un "software" para hacer un
servicio, por ejemplo, leer documentos PDF, tienes que ponerlo en la cadena de servicios, en la
gestión de la demanda a nivel de la estrategia. Después concebir, una vez que tiene la
autorización, el "pack" de despliegue para después pasarlo a la transición. Sin embargo, todo esto
hay que hacerlo muy rápidamente. Cuando un usuario pida Acrobat Reader, esto tiene que ser al
menos tan rápido como si se lo descargase él mismo por Internet. Por todo ello, tenemos métodos
de trabajo. La idea es verdaderamente que todos los servicios que la gente, los clientes, los
usuarios puedan necesitar, ya se hayan previsto en el catálogo, incluso aquellos en los que quizás
no hayamos pensado en primer lugar. A continuación, en la gestión de subprocesos tienes la
famosa gestión de activos y configuraciones. ¿De qué se trata? De mantener actualizadas
obligatoriamente todas las entradas en la base de datos, todos tus CI y activos en tu
empresa. Entonces, todo lo que tienes (materiales, "software", competencias humanas, controles
de subcontratos, SLA, OLA, UC, informes de los servicios, etc.), toda esa masa de conocimientos,
de informaciones, tu lista de proveedores, tu DLM, todo eso tiene que estar bien almacenado en
las bases de datos y TILT te dice: haz una base de datos. Pero no te recomienda ningún producto
del mercado. Hay muchos productos que son de una excelente calidad, pero que dependen todos
del nivel de madurez de tu empresa. No sirve de nada comprar un "software" muy
pesado, complejo, que cuestan mucho, que son 100 % ITIL, si en tu empresa ni siquiera eres capaz
de convencer a la Dirección para que inviertan en estrategia. Esto no servirá de nada. Por ejemplo,
te piden que uses una herramienta pero en realidad ITIL no te prohíbe que lo hagas tú mismo
en una libreta con una tabla para hacer tu base de datos. En estos subprocesos, vamos a pensar en
la formación: tanto en la formación de los usuarios del futuro servicio como de aquellos que se
encargarán del soporte técnico. Pensaremos, a la vez, en las personas del servicio de informática,
en los de soporte nivel dos, nivel tres, según tu organización informática interna. Después, como
ITIL se basa en el sentido común y puesto que intentamos actuar de manera inteligente, nos
decimos: voy a poner en marcha un nuevo servicio, pero ¿realmente y de manera inmediata voy
a recuperar el valor añadido? Sabes bien que incluso con formación, incluso con un servicio
extremadamente bien implementado, se necesitará un cierto tiempo para que los
usuarios controlen correctamente el nuevo servicio. Entonces, en este nuevo servicio serán menos
productivos. Por ejemplo, imagina el paso de una versión de Microsoft Office a otra. Vamos a
perder parte de nuestras referencias en la interfaz o incluso configuraciones propias de cada
usuario. Entonces la productividad que hubiéramos podido tener, tal como la presenta Microsoft,
no será instantánea. Por ello, ITIL prevé lo que llamamos "Soporte de inicio de vida", es decir, ITIL
te dice: durante un cierto tiempo que vas a calcular los SLA y el valor no alcanzarán el nivel
esperado. Sin embargo, estimamos que la salida del Soporte de inicio de vida se hará en un
mes, dos meses, tres meses. Entonces ves que ITIL se basa en el sentido común, incluso si te
formas de la noche a la mañana, te damos una nueva herramienta. Evidentemente, no estarás al
100 % operacional para crear valor, hay tiempo de adaptación. Esto es parte de lo que ya se ha
previsto y se ha pensado en ello. ¿Por qué? Porque se trata de la acumulación de
experiencias, que es de lo que estamos hablando desde el inicio de este curso. No se trata de
teoría, sino verdadera acumulación de experiencias reales.
Discernir el objetivo de la operación
Llegamos a la operación del servicio, ya que ahora nuestro servicio es operativo. ¿Cuál es el

objetivo de la operación del servicio? Se trata de garantizar que el servicio siempre se encuentra
entre los límites de los SLA acordados, hacer mantenimiento preventivo, solución de
problemas, intentar acumular un máximo de datos para la mejora continua, proporcionar los
conocimientos técnicos de primer, segundo y tercer nivel para el soporte técnico, gestionar el
servicio de ayuda de Help Desk, que será el Single Point of Contact, el punto de contacto único
entre los usuarios del servicio informático, gestionar también todo el Back Office, es decir, lo que
se guarda, las operaciones de rutina de mantenimiento informático y la gestión del entorno
físico. Se trata, por ejemplo, de la parte inmobiliaria, de refrigeración, de la electricidad, de la
gestión de los Data Centers, etc. Se trata también de la gestión de acceso, que no se debe
confundir con la gestión de seguridad. Por último, hay que garantizar también que el valor que
se predijo al inicio de la estrategia es finalmente real, modelizado y mantenido durante las
operaciones en ese momento del ciclo y ahí vemos de verdad si lo que habíamos predicho ocurre
realmente. Entonces salimos del Early Life Support, del soporte inicial, y veremos a ver si
realmente todo funciona como se ha previsto. ¿Se ha creado valor o me doy cuenta en ese
momento, haciendo un cierto número de comparaciones, que nadie usa el servicio? ¿O me doy
cuenta que en el servicio tengo muchas llamadas al soporte técnico y que la gente me dice que tal
o tal función no funciona o que no saben cómo usarla? A partir de todos esos datos, podremos
proceder a acciones correctivas, pero, como lo habrás entendido, pasamos mucho tiempo a la
corrección en operación porque la idea es ser proactivo al máximo y, si lo eres, la estrategia, el
diseño y entonces la concepción y la transición han hecho su trabajo al máximo. Normalmente la
producción y la operación del servicio deberán automatizarse al máximo y deberían robarte el
menor tiempo posible para dejarte un pequeño margen para hacer mejora continua. Imagino que
para ti, como parte del personal de informática, es más interesante concebir nuevos servicios que
hacer despliegue puesto por puesto de Office o, por ejemplo, ayudar a las personas que se
olvidaron su contraseña.
Descifrar el subproceso de la operación
En los subprocesos y funciones que subyacen a la operación del servicio, encontrarás
rápidamente servicio de Help Desk. El servicio de Help Desk es el servicio de soporte al que se han
de dirigir todos los usuarios de los servicios. Esto significa que en la empresa nadie podrá
abordarte en la pausa del café para que le saques las castañas del fuego. También significa que
toda solicitud de intervención tiene que ser objeto de la creación de un "ticket". Al principio los
usuarios son más bien reticentes. Los "tickets" son la única solución que tienes para
almacenar información y demostrar que tu actividad tiene valor añadido, tal como se ha
presentado desde el inicio. Te pongo un ejemplo. Si te digo: "A partir de ahora externalizamos el
servicio de Help Desk porque nos cuesta muy caro". Tienes que estar en capacidad de decir, como
responsable actual del servicio dentro de la empresa: "Costamos tanto pero aportamos
tanto, siempre estamos en los SLA que nos asignan, tenéis un soporte técnico donde el 95 % de los
incidentes se arreglan en menos tiempo del necesario y os ofrecemos un servicio de calidad que
no estamos seguros que un externo pueda realizar porque tenemos un conocimiento pleno de la
empresa". Si no eres capaz de probar estas cosas, tendrás muchas dificultades. Si te das cuenta de
que muchos usuarios piden a menudo explicaciones de un "software", puedes hacer estadísticas y
deducir de ahí un tiempo de formación. Si lo deduces, puedes ir a ver al departamento
de Recursos Humanos y decirle: "En el plan de formaciones previstas, este grupo de usuarios
necesitarán una formación específica sobre esta o aquella funcionalidad de este o aquel
'software'". Entonces, en realidad, ayudas a las decisiones. Esto es nuestro servicio de Help
Desk. Este servicio de Help Desk es lo más visible dentro de los servicios informáticos. Es
importante que sea de calidad. ¿Por qué? Porque te costará pedir a las personas que sigan estos
procedimientos si tú mismo no lo haces y no gestionas perfectamente las diferentes solicitudes
que se te entregan en el servicio de Help Desk. A continuación, tendrás el servicio de gestión de
tareas corrientes. Se trata de gestionar los grandes volúmenes de impresión y ciertas tareas en
grandes centros de cálculo, sobre todo en los grandes sistemas. También tienes la gestión del
entorno, lo que llamamos "facilities", en inglés. Se trata de gestión de los centros de datos, del
suministro eléctrico, la gestión inmobiliaria, etc., y la refrigeración también cada vez más. También
tendrás la gestión de eventos, es decir, toda la información significativa que se recopila a través de
herramientas informáticas o por cualquier otro medio. Por ejemplo, un usuario que se queja de un
ruido extraño en el ordenador. Además del tratamiento de eventos, también tendremos el
tratamiento de incidentes. Un incidente es un evento que potencial o actualmente puede hacer
bajar el SLA de un servicio. Por último, una tercera gestión es la de los problemas. Un problema es
un incidente particular del que no conocemos la causa primaria o raíz. Ya tienes, entonces, una
definición muy precisa de lo que supone gestionar los eventos, gestionar los incidentes y gestionar
los problemas, aunque el procedimiento para cada uno de estos puntos es estrictamente
diferente. Los procedimientos serán específicos con niveles de dificultad, con plantillas para
poder hacerse las preguntas correctas y tomar decisiones, como reparaciones, lo más rápidamente
posible. Alternativamente, los procedimientos tendrán una base de datos de todos los errores
cometidos. Si dispones de una base de datos de errores conocidos, serás capaz de encontrar lo
que se denomina en inglés "walk arounds", es decir, atajos para que el usuario alcance un nivel de
servicio aceptable, mientras no descubramos una solución definitiva que puede ser un "patch" o
una nueva actualización, etc. También tenemos la gestión de accesos, que no es más que la
implementación de la política de seguridad. Te recuerdo que la política de seguridad se define
a nivel del servicio de creación o concepción. En concepción, hemos definido cuáles serán las
políticas de acceso en cuanto a la operación del servicio. Se aplicará para verificar que las personas
que tienen que acceder a los recursos tienen los accesos y que los que no deben acceder, ya no los
tienen. Entonces, verificar, sobre todo en correlación con los recursos humanos, las personas que
entran y salen o que cambian de empleo en el interior de tu organización. Esto necesita un
seguimiento y la firma de un OLA con las personas de Recursos humanos, porque no puedes
adivinar en una empresa grande a quién se contrató, quién cambió de puesto, quién se fue o
quién se despidió. Nos encontramos a menudo en las grandes empresas que hay casos en que las
personas siguen teniendo acceso cuando hace dos o tres años que no están. La operación del
servicio va a gestionar todo este conjunto de cosas cada día y, sobre todo, va a acumular datos de
todo tipo. Es a partir de estos datos que se acumulan que podremos comenzar a trabajar a
continuación en la mejora continua de servicios.
Desvelar el objetivo de la mejora continua de los servicios
El objetivo de la etapa del ciclo de vida o Continuous Service Improvement o Mejora continua de

los servicios, en español, consiste en encontrar a lo largo de todo el ciclo de vida posibilidades de
mejora de los procesos ya existentes. Trabajaremos por ello en varios niveles. Trabajaremos a
nivel de los servicios de principio a fin, en cómo mejorar un servicio, trabajaremos también en
cada proceso. Un proceso puede mejorarse en términos de calidad y de rapidez y también vamos a
ser capaces de trabajar en términos de componentes de los servicios, como un "hardware" o
elementos físicos más eficaces, un programa con más detenimiento o nueva formación. Podremos
además mejorar el ITSM, es decir, la ciencia de la gestión de servicios informáticos en sí misma. Ya
lo hemos tratado previamente, por ejemplo, para la creación o concepción, digamos, la primera
vez, que nos va a llevar tres meses y vamos a realizar quizá dos o tres versiones. A continuación, a
fuerza de la acumulación de conocimientos de los modelos que crearemos, invertiremos mucho
menos tiempo y conseguiremos directamente una versión que será la definitiva. Para poder
fabricar esta mejora continua, son necesarias una serie de medidas que se tomarán en todos los
momentos del ciclo de vida de los servicios, desde la estrategia hasta el mismo servicio de mejora
continua. Para ello, tendremos instrumentos de medida que ya están definidos en la fase de
concepción y empezaremos siempre desde una línea de base, es decir, de un punto dado. Si no
partimos desde un punto dado, jamás podremos llevar a cabo una mejora, ya que esta es un plus
en relación a una base dada. Para ello, vamos a utilizar estas líneas base, realizar mediciones,
analizarlas, extraer información de esas mediciones en bruto y, a partir de esta información, tomar
simplemente decisiones que nos permitan proponer mejoras nuevas. Si estas mejoras conducen a
solicitudes de cambio en ese momento, ¿qué pasará? Pues que volveremos al ciclo de vida como
estrategia en la gestión de la solicitud a nivel del portafolio y veremos si estas mejoras son o no
rentables en relación con la inversión necesaria. Podremos tomar decisiones con todo
conocimiento de causa y habrá, por supuesto, que determinar si el valor recientemente creado
o mejorado será superior al gasto necesario para su realización. También veremos al cabo de
cierto tiempo este valor estimado, es decir, el retorno de nuestra inversión. Si el retorno sobre la
inversión no es mucho, quizá no sea necesariamente oportuno lanzar esta iniciativa en un
momento dado de la vida de la empresa. Por lo tanto, se anotará toda la información en un
registro y clasificaremos estas iniciativas de mejora continua como importante, menos
importante, accesoria y también como corto plazo, medio plazo y largo plazo. cada una de ellas
será generada en cada gestión de proyecto.
Aprehender el subproceso de la mejora continua de servicios

ITIL va a darnos un procedimiento de siete etapas que, de hecho, es el único subproceso de esta
parte del ciclo de vida. Nos ayudará a establecer una mejora continua. Estas siete etapas son, en
primer lugar, la identificación. ¿Qué nos pide ITIL que hagamos, como ciencia de gestión
de sistemas de información? Por lo tanto, vamos a identificar los diferentes elementos
que tendremos que medir, los diferentes elementos por los que tendremos que interesarnos. La
segunda etapa será la de definir con precisión, a continuación, cuáles son las métricas que se
deben recabar. Podrán ser, por ejemplo, el rendimiento de un ordenador, el rendimiento de un
proceso, el rendimiento de una persona, etc. A continuación, recogeremos estos
datos, definiremos su formato, cuándo y cómo serán recogidos y cómo comprobaremos la
coherencia de los mismos. La etapa siguiente consistirá en tratar estos datos, es decir, en
transformar estos datos en información. Esta información en curso de tratamiento nos dará un
cierto número de tendencias que analizaremos. Este análisis va a permitirnos, a
continuación, fabricar un cierto número de cuadros de objetivos dirigidos a los diferentes
servicios, componentes de la empresa. Este análisis va a permitirnos, a continuación, fabricar un
cierto número de cuadros de objetivos dirigidos a los diferentes servicios, competentes de la
empresa. Podremos implementar cuadros de objetivos para recursos humanos, por ejemplo, para
explicar que se necesita esta o aquella acción de formación, cuadros de objetivos financieros que
ayudarán a justificar nuestras futuras inversiones, cuadros de objetivos informáticos para ver en
qué punto se encuentra el rendimiento de nuestros recursos. Finalmente, una vez que hayamos
presentado todas estas medidas de mejora a los diferentes socios de la empresa, a las diferentes
partes interesadas, podremos establecer la implementación. Reconocerás entonces en estos siete
elementos el Plan, Do, Check, Act del ciclo de Deming.
Seguir los consejos y las buenas prácticas para continuar con ITIL
En esta introducción a la metodología ITIL 2011 hemos visto el vocabulario, el historial y la filosofía
del método, así como el funcionamiento en modo ciclo de vida. Habrás entendido que el método
es mucho más amplio y que tan solo hemos esbozado las posibilidades del mismo. Tienes ahora
una metodología en forma de círculos cerrados y tendrás que preguntarte: ¿por dónde voy a
empezar la implementación? Para responder a esta pregunta, te voy a dar algunos consejos que se
aplicarán en función del tipo de organización que tengas. Si trabajas en una empresa
extremadamente estructurada como, por ejemplo, las organizaciones industriales a las que ya
se les exige unas metodologías con mucho seguimiento que, además, normalmente cuentan con
certificación ISO, como ocurre con frecuencia en la industria farmacéutica o este tipo de
actividades, te resultará muy sencillo implementar ITIL porque la cultura del proceso y la de la
industrialización ya están presentes. De este modo, podrás empezar a poner en marcha
ITIL, estableciendo todos los procesos empresariales así como también todos los procesos
informáticos existentes. Por ejemplo, verás cómo actualizar una contraseña, cómo crear un nuevo
usuario, cómo actualizar todas las copias de seguridad, cómo retirar un servidor, cómo añadir uno
nuevo y, desde este punto, todas las operaciones que tendrás que hacer cada día en el entorno
informático tendrán que seguir unos procedimientos. En otros casos, en las empresas que sean
algo menos maduras, desde el punto de vista industrial, te aconsejo que en primer lugar crees un
servicio de Help Desk de gran calidad. Si instauras un servicio de Help Desk de gran calidad que
refleje un funcionamiento informático extremadamente riguroso que aporte soluciones
rápidas, eficaces, serás el modelo que permitirá al resto de la empresa seguir y adoptar esta
gestión. No hay nada más complicado, cuando hay un servicio Help Desk con fallos, que convencer
al resto de la empresa de adaptar un cierto número de procedimientos ITIL. Otra posibilidad para
poder iniciarte en el mundo ITIL es la de fabricar tu propia CMDB. Se trata de tener un inventario
de todos tus archivos informáticos, virtuales o físicos, competencias, procesos, subcontratos todos
englobados en una base de datos. Existe una posibilidad más en función de la madurez de tu
empresa. Este es, por ejemplo, un caso ideal. Imaginemos que la empresa es muy consciente del
valor añadido por la informática y directamente comienzas poniendo en marcha una
estrategia. Esto significa una implicación de la empresa para celebrar cierto número de reuniones
y definir el marco de lo que podrá ser después tu acción, tanto en el marco del servicio informático
como en el de la creación de valor. Sobre todo, no empieces comprando "software" que te
ayude. Es, de verdad, la última acción que hay que hacer y, además, te sobrará dónde elegir. La
gama de "software" es muy amplia, va desde la pyme más pequeña, con algunos puestos, hasta las
empresas muy maduras, con cientos de miles de puestos. Entonces el "software" no te va a
solucionar nada, no creará los procesos por ti y, sobre todo, no pondrá en marcha el factor crítico
de éxito. Te lo recuerdo: hay que unir la empresa e IT. Y para ello el concepto esencial es la
comunicación entre las dos entidades. IT y la empresa deben comunicarse permanentemente. La
empresa está, por definición, cambiando constantemente y, por lo tanto, siempre tendrás que
adaptarte. Estos son algunos consejos de buenas prácticas para entrar en el mundo de ITIL sin
muchas dificultades. Después, tranquilamente con pequeños proyectos, podrás mejorar y poner
en marcha servicios y procesos ITIL. Una cosa es segura: nunca acabarás, porque el ciclo de vida no
tiene fin.

Curso ITIL Fundamentos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso ITIL Fundamentos

Cargado por

Copyright:

Formatos disponibles

Presentación del curso “Fundamentos de ITIL: Introducción a la gestión de sistemas de

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

La Biblioteca de Infraestructura de Tecnologías de Información o ITIL es la aproximación de gestión

Comprender la metodología de gestión de los sistemas de información

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Conocer el origen de ITIL

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

El origen de ITIL nace en el mundo anglosajón y proviene específicamente de los británicos que, en

Apoyarse en los puntos fuertes del método

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Integrar ITIL con otros métodos

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Adaptar tus prácticas con ITIL

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Basarse en la experiencia vivida

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Toda la riqueza de la metodología ITIL proviene de lo que es: una compilación de experiencias de

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Abordar las diferentes versiones de ITIL

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Gestionar el ciclo de vida de los servicios

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

ITIL se basa en un ciclo de vida de servicios. Definiremos de manera precisa qué es un

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Cuando la empresa y IT hablan la misma lengua

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Mejorar continuamente el ciclo de vida ITIL

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

En el marco de ITIL vamos a trabajar bajo el modo cliente/proveedor. El cliente se definirá en ITIL

Examinar al proveedor del servicio

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Entendemos por "proveedor del servicio" el servicio informático de una empresa u

Definir el proveedor externo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Un servicio es un conjunto en ITIL de diferentes componentes que sumados se destinan a proveer

Tener nociones sobre el usuario

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Apoyarse en el nivel de servicios OLA

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Interesarse por el nivel de servicio

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Definir el objetivo de la estrategia

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Evaluar el subproceso de la estrategia

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Comprender el objetivo de la concepción

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Descubrir el subproceso de la concepción

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Definir el objetivo de la transición

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

El objetivo de la transición de servicios es la construcción y preparación para producir servicios

Explotar el subproceso de la transición

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el vídeo

Llegamos a la operación del servicio, ya que ahora nuestro servicio es operativo. ¿Cuál es el

Descifrar el subproceso de la operación