- Introducción a
ITIL - El objetivo de usar ITIL en
Managed Services - Concepto de soluciones para ITIL
desde el punto de vista de negocio - Forma de uso de ITIL en Managed
Services - Proceso de manejo de
incidentes - Proceso de manejo de
problemas - Proceso de manejo de
configuraciones - Proceso de control de
cambios - Proceso de manejo de
entregas - Conclusiones
- Limitaciones del
proyecto
ITIL son las siglas de una metodología desarrollada a finales de los
años 80’s por iniciativa del gobierno del
Reino Unido, específicamente por la OGC u Oficina
Gubernativa de Comercio
Británica (Office of
Goverment Comerce). Las siglas de ITIL significan (Information
Technology Infrastructure Library) o Librería de
Infraestructura de Tecnologías de Información.
Esta metodología es la aproximación
más globalmente aceptada para la gestión
de servicios de
Tecnologías de Información en todo el mundo, ya que
es una recopilación de las mejores prácticas tanto
del sector
público como del sector privado. Estas mejores
practicas de dan en base a toda la experiencia adquirida con el
tiempo en
determinada actividad, y son soportadas bajo esquemas
organizacionales complejos, pero a su vez bien definidos, y que
se apoyan en herramientas
de evaluación
e implementación.
El objetivo de
usar ITIL en Managed Services
ITIL como metodología propone el establecimiento
de estándares que nos ayuden en el control,
operación y administración de los recursos (ya sean
propios o de los clientes).
Plantea hacer una revisión y reestructuración de
los procesos
existentes en caso de que estos lo necesiten (si el nivel de
eficiencia es
bajo o que haya una forma mas eficiente de hacer las cosas), lo
que nos lleva a una mejora continua.
Otra de las cosas que propone es que para cada actividad
que se realice se debe de hacer la documentación pertinente, ya que esta puede
ser de gran utilidad para
otros miembros del área, además de que quedan
asentados todos los movimientos realizados, permitiendo que toda
la gente este al tanto de los cambios y no se tome a nadie por
sorpresa.
En la documentación se pone la fecha en la que se
hace el cambio, una
breve descripción de los cambios que se hicieron,
quien fue la persona que hizo
el cambio, así como quien es el que autorizo el cambio,
para que así se lleve todo un seguimiento de lo que pasa
en el entorno. Esto es más que nada como método con
el que se puede establecer cierto control en el sistema de
cambios, y así siempre va a haber un responsable y se van
a decir los procedimientos y
cambios efectuados.
Concepto de
soluciones
para ITIL desde el punto de vista de negocio
Según este diagrama vemos
como aparentemente tenemos segmentos del negocio aislados, pero
en realidad todos tienen algo que ver para la obtención de
las soluciones. Por ejemplo la prestación de servicios
muchas veces no seria posible sin la gestión de
infraestructura, asimismo las perspectivas del negocio no se
darían sin la prestación de servicio y los
servicios no serian posibles sin un soporte al servicio. Y el
punto de interacción que se da entre estos segmentos
del negocio es la búsqueda de soluciones, donde lo que se
busca es que las perspectivas del negocio estén soportadas
en base a la prestación de servicios; la prestación
de servicios requiere que se le de un soporte al servicio para
que este siempre disponible, la disponibilidad la podemos lograr
mediante una gestión de la infraestructura y en lugar de
tener al centro las soluciones vamos a tener a los clientes
satisfechos.
Forma de uso de ITIL en Managed
Services
ITIL postula que el servicio de soporte, la
administración y la operación se realiza a
través de cinco procesos:
- Manejo de Incidentes
- Manejo de problemas
- Manejo de configuraciones
- Manejo de cambios y
- Manejo de entregas
Proceso de
manejo de incidentes
Su objetivo primordial es reestablecer el servicio lo
mas rápido posible para evitar que el cliente se vea
afectado, esto se hace con la finalidad de que se minimicen los
efectos de la operación. Se dice que el proveedor de debe
de encargar de que el cliente no debe percibir todas aquellas
pequeñas o grandes fallas que llegue a presentar el
sistema. A este concepto se le
llama disponibilidad (que el usuario pueda tener acceso al
servicio y que nunca se vea interrumpido).
Para este proceso se
tiene un diagrama que en cada una de sus fases maneja cuatro
pasos básicos que son: propiedad,
monitoreo, manejo de secuencias y comunicación.
En el proceso de manejo de incidentes vemos que se da
como primera etapa la detección del incidente (es cuando
el sistema presenta alguna anomalía o falla, y que esto se
puede traducir en un error en el sistema o que el usuario no
puede hacer algo y recurre a pedir ayuda); ya que lo tenemos
identificado se hace una clasificación del incidente
(vemos si el error que se presenta es conocido o si nunca se ha
presentado) y de la mano va el soporte inicial (es el punto en el
que el cliente llega a la mesa de servicio a solicitar ayuda,
porque no sabe o no puede hacer algo); en caso de que el
incidente sea conocido se hace el procedimiento de
solicitud de servicio (se ejecutan los pasos a seguir
según el manual de
procedimientos para poder llegar a
la solución de una forma viable y eficiente); una vez que
ya que se la dio una solución al incidente por medio del
manual de
procedimientos se recurre a la documentación y
contabilización del incidente, para ver que tanta
incidencia tiene este caso; finalmente se hace una
evaluación para ver si efectivamente se resolvió el
incidente de forma satisfactoria y en supuesto de ser afirmativa
se cierra el incidente y el otro supuesto seria que de la
solución que se planteo no es lo suficientemente eficiente
o acertada para que resuelva el problema y se recurre a hacer una
investigación y un diagnostico de la
situación para ver como es que se puede atacar el problema
de frente y resolverlo; una vez que se tiene todo un contexto
analizado se recurre a la ejecución de la propuesta de
solución del incidente y se hace un estudio para ver si el
incidente es recuperable o si es caso perdido (la mayoría
de los casos son recuperables, peo cuando el nivel de daño es
muy fuerte, se da el caso de que se de por perdido); y finamente
se cierra el incidente y esta solución se documenta en una
base de datos
a la que se le llama base del conocimiento o
Knowledge Data Base (aquí vienen documentadas todas las
soluciones, y se establecen los pasos a seguir para que se hagan
de forma eficiente) para que al momento de volverse a presentar
el incidente ya va a estar documentado y esto hace que sea mas
fácil, rápida y eficiente su
resolución.
Proceso de
manejo de problemas
El Objetivo de este proceso es prevenir y reducir al
máximo los incidentes, y esto nos lleva a una
reducción en el nivel de incidencia. Por otro lado nos
ayuda a proporcionar soluciones rápidas y efectivas para
asegurar el uso estructurado de recursos.
En este proceso lo que se busca es que se pueda tener
pleno control del problema, esto se logra dándole un
seguimiento y un monitoreo al problema.
El diagrama de este proceso es muy particular, ya que se
maneja en dos fases: la primera esta relacionada con lo que es el
control del problema y la segunda es con el control del
error.
En lo que respecta a la fase de control del problema:
primero se tiene que identificar el problema en base a alguna
sintomatología; ya que tenemos este antecedente, pasamos a
la clasificación de los problemas (en
este proceso al igual que en el proceso de manejo de incidentes
tenemos que ver si es un problema conocido), en caso de ser
conocido, se recurre al procedimiento de solicitud de servicio,
donde se van a aplicar las soluciones de acuerdo a como
están en el manual de procedimientos; y en caso de no ser
conocido se tendría que hacer una fase de
investigación para ver que es lo que genera el problema y
mas tarde hacer un diagnostico; ya que tenemos un diagnóstico tenemos que hacer un RFC
(Request For Change o Solicitud de Cambio),
Esta solicitud de cambio implica que se va a tener que
implementar la solución y finalmente se va a hacer una
evaluación para ver si se resolvió el problema de
raíz. En caso de que si se funcione esta solución
se pasa a la documentación.
Con lo que respecta a la segunda fase del modelo, el
control del error se hace por medio de una identificación
del error en general, posteriormente se hace una especie de
registro, y
este va a servir para clasificar el error; ya que se tiene una
clasificación y se recurre a una evaluación de que
tanto daño genero o puede
llegar a generar el error, esto con la finalidad de cuantificar
los desperfectos que podría llegar a causar en caso de que
el error prevalezca y no se solucione; posteriormente se hace la
resolución o corrección del error (este puede
deberse a varios aspectos: configuraciones, falta de seguridad,
inconsistencia de datos, etc.); y
este modelo tiene una fase muy difícil, que es determinar
que problemas están asociados o como es que al momento de
cambiar algo el sistema, se va a cambiar de forma uniforme y no
se va a alterar, y que presente inconsistencias. Por ejemplo que
es lo que pasaría si cambio algunos de los datos en la
configuración del sistema, se tendría que afectar
el sistema de manera uniforme para que siga en equilibrio y
no este cambiado en algunas partes y en otras que se quede como
estaba antes.
Proceso de
manejo de configuraciones
Su objetivo es proveer con información real y
actualizada de lo que se tiene configurado e instalado en cada
sistema del cliente.
Este proceso es de los más complejos, ya que se
mueve bajo cuatro vértices que son: administración de cambios,
administración de liberaciones, administración de
configuraciones y la administración de procesos
diversos.
El nivel de complejidad de este modelo es alto, ya que
influyen muchas variables y
muchas de ellas son dinámicas, entonces al cambiar una o
varias de ellas se afecta el sistema en general, lo que hace que
sea muy difícil de manipular. Aunque es lo más
parecido a la realidad, porque nuestro entorno es dinámico
y las decisiones de unos afectan a otros.
Por ejemplo en lo que respecta a la
administración de cambios vemos que se relaciona
directamente con la administración de incidentes y de
problemas, lo que conlleva una planeación, identificación, control,
seguimiento del status, verificación y auditoria de
configuraciones, lo que hace que haya muchas
variables.
En otro ejemplo la implementación de cambios
implica que se tiene que hacer la liberación y distribución de nuevas versiones, esto de
da por una fase de planeación, identificación,
control, revisión del status, verificación y
auditoria, y puede depender de la administración de las
capacidades, ya que si no se cuenta con el software o con el hardware esta fase no se
podría llevar a cabo; y así se haría con
todos los niveles hasta llegar al cierre del control de
cambios.
El objetivo de este proceso es reducir los riesgos tanto
técnicos, económicos y de tiempo al momento de la
realización de los cambios.
Este diagrama la parecer es muy fácil de seguir,
pero en realidad no lo es, ya que entre etapa y etapa se da una
fase de monitoreo para ver que no se han sufrido desviaciones de
los objetivos.
Primero vemos que tenemos un registro y
clasificación del cambio que se tiene que hacer, se pasa a
la fase de monitoreo y planeación, si el rendimiento es
satisfactorio se da la aprobación del cambio, y
en caso de que el rendimiento sea malo se pasa a la fase
de reingeniería hasta que el proceso funcione
adecuadamente, ya que se aprueban los cambio, se construyen
prototipos o modelos en los
que se van a hacer las pruebas, se
hacen las pruebas pertinentes para ver las capacidades del
sistema, ya que el proceso esta probado se da la
autorización e implementación; ya implementado se
ve que no se hayan tenido desviaciones y se ajusta a las
necesidades actuales que también se le considera como
revisión post-implementación
Su objetivo es planear y controlar exitosamente la
instalación de Software y Hardware bajo tres ambientes:
ambiente de
desarrollo,
ambiente de pruebas controladas y ambiente real.
Este proceso tiene un diagrama que marca la
transición que se da de acuerdo a los ambientes por los
que se va dando la evolución del proyecto.
En lo que respecta al ambiente de desarrollo vemos que
se tiene que hacer la liberación de las políticas,
la liberación de la planeación, el diseño
lógico de la infraestructura que se va a implementar y la
adquisición de software y hardware están entre los
ambientes de desarrollo y de pruebas controladas; ya que se
requiere que ambos hagan pruebas sobre ellos; en el ambiente de
pruebas controladas vemos que se hace la construcción y liberación de las
configuraciones (nivel lógico), se hacen las pruebas para
establecer los acuerdos de aceptación; se da la
aceptación total de versiones y de modelos, se arranca la
planeación y finalmente las pruebas y comunicaciones; y en lo que es el ambiente real
vemos que se da la distribución e
instalación.
En la etapa del ambiente real es la que se ve de forma
mas concreta, ya que muchas veces no tenemos idea de todo lo que
pasa hasta antes de la instalación.
En el proceso de entrega del servicio es el punto en el
que el usuario hace uno del servicio y no sabe que detrás
de el servicio que esta recibiendo hay un sin fin de actividades
y de decisiones que se tuvieron que tomar para que llegar a este
punto.
Este proceso es en el que mas cuidado debemos de poner,
ya que en caso de haber fallas, el primero en detectarlas o en
percibirlas es el usuario, y eso nos genera que el cliente este
insatisfecho o molesto. Por lo general los usuarios no saben que
para que puedan hacer uso de los servicios, se paso por una fase
de planeación, monitoreo, análisis y por un sin fin de pruebas, con
la intención de que en caso de que algo no funcione, se de
en la fase de pruebas controladas y no en la fase de pruebas en
ambiente real, donde el mayor afectado es el cliente.
ITIL es una metodología que nos va a ayudar a que
las cosas se puedan hacer de una forma más eficiente, ya
que lo que se propone es que se adopten ciertas métricas y
procedimientos que otros proveedores de
IT adoptaron y que gracias a ellas son catalogadas como mejores
prácticas.
El hecho de adoptar mejores practicas implica que no
tengamos que descubrir el hilo negro y que si alguien sabe como
hacer las cosas y explotar los recursos nos podemos apoyar en el
para que nosotros también podamos hacerlo. E mayor
objetivo es que todos lleguemos a un nivel de eficiencia que se
traduzca en una buena prestación de servicios.
Creo que me tope con muchas limitaciones, yo nunca
creí que me enfrentaría a tantas trabas, pero me di
cuenta de que al ser un tema totalmente nuevo, el horizonte de
posibilidades se reducía a gente que es experta en el
tema, ya que casi ningún maestro de la carrera sabe que es
ITIL, y creo que es conveniente que se metan en el tema, porque
el hecho de adoptar mejores practicas hace que se den las cosas
de una forma mas eficiente.
Otra de las limitaciones con las que me tope fue que en
ocasiones los consultores no tenían tiempo y tenia que
andarlos presionando para que me prestaran la información
necesaria para hacer la investigación y algo que me
decían a cada rato es "esta información es
confidencial, puedes leer todo lo que quieras, pero no te puedes
llevar ningún archivo".
Casi no hay literatura en México de
este tema, lo que hizo que me tardara un poco en conseguir las
fuentes. Mi
hermano me presto unos manuales
introductorias de ITIL que se usaron en la implementación
de ITIL en HP, y me fueron de mucha utilidad, cabe mencionar que
todas las fuentes están en ingles, y creo que
deberíamos hacer lo posible por que haya fuentes en
español.
Muchos mexicanos no saben hablar inglés
y creo que esta metodología sería mucho
apoyo.
- http://www.ati.es/article.php3?id_article=294
- http://ar.groups.yahoo.com/group/foro-itil/
- Manuales de introducción a la implementación
de ITIL. - PDF’s de Internet.
Tesis de
Carlos Alejandro Hernández
García
Alumno de la Universidad
Iberoamericana Campus Cuidad de México.