RSS |

Blog de Omar

Just another WordPress weblog

Advertisement

Posts Tagged ‘ ITIL ’

que-es-itilFue hace ya bastante cuando decidí estudiar ITIL por primera vez, no me pareció difícil porque en el ambiente donde trabajaba se respiraba una atmosfera innata de gestión de servicios. Cuando comencé a estudiar me preocupé mucho por entender claramente de que se trataba y como se podía llevar a la práctica ITIL, es decir, implementarlo en el área donde trabajaba ; en ese momento no me preocupaba en lo más mínimo obtener un certificado y postergué esa tarea de manera indefinida.

Hace cuatro semanas decidí repasar algunos términos de ITIL y obtener el certificado ITIL Foundation, al parecer mucha gente le da un valor extremadamente alto a los certificados así que decidí obtenerlo . Lo cierto es que hay muy poco material de ITIL en español así que he decidido compartir el material que utilicé para certificarme con los visitantes de mi blog:

Material de ITIL v3

Yo he escrito material de ITIL en español, siento que desarrollé un buen material y de los pocos que hay en español.

  • INTRODUCCIÓN A ITIL v3: Documentación en español AQUÍ
  • ESTRATEGIA DEL SERVICIO: Documentación en español AQUÍ
  • DISEÑO DEL SERVICIO: Documentación en español AQUÍ
  • TRASICIÓN DEL SERVICIO: Documentación en español AQUÍ
  • OPERACIÓN DEL SERVICIO – Parte 1: Documentación en español AQUÍ
  • OPERACIÓN DEL SERVICIO – Parte 2: Documentación en español AQUÍ

Además, comparto el material extra que tengo de ITIL y algunos preguntas tipo examen de certificación: AQUÍ (contraseña del archivo: www.el-palomo.com)

Por cierto, por fin llego mi certificado ITIL, aquí lo comparto:

 

image

 

 

itil

Popularity: 57% [?]

 

helpdsk Voy a tratar de ser breve porque el primer post sobre Service Operation me explaye bastante pero creo que valía la pena. Hasta ahora hemos tocado los siguiente capítulos de ITIL v3:

- Introducción a ITIL v3
- Estrategia del Servicio
- Diseño del Servicio
- Transición del Servicio
- Service Operation – Parte I

Es evidente que para poder entender en su totalidad este post, les recomiendo antes haber leído los posts arriba mencionados. La Operación del Servicio (SO) se encarga de mantener que todos los servicios funcionen correctamente siempre, se encarga de las operaciones del día a día y son los que tienen contacto directo con los usuarios. ¿Quienes son los que realizan este trabajo? Existe un grupo humano encargado de realizar esta laboriosa y a veces tedioso trabajo, ellos son los chicos de SERVICE DESK.

Si alguien pensó que la respuesta a la pregunta era HELP DESK, no lo culpo porque es la respuesta mas lógica y la que seguro la mayoría de las personas, que inclusive están envueltos en el mundo de IT, hubieran respondido.

¿Service Desk o Help Desk?

Para comenzar a despejar el panorama sobre la diferencia entre ambos es importante recalcar que la principal diferencia radica en una nueva manera de atender a los usuarios finales. En términos prácticos Service Desk esta un nivel mas arriba que Help Desk ya que contiene nuevas funciones que mejoran todo el proceso de Service Operation. No desesperen que mas abajo lo explico mejor y prometo que al terminar de leer esto van a entender claramente la diferencia.

¿Donde trabaja Service Desk?

ITIL v3 indica que Service Desk actúa sobre la Gestión de eventos, Gestión incidentes y cumplimiento de solicitudes. ¿Actúa sobre la Gestión de problemas y la Gestión de Acceso? La respuesta es obvia, NO!! la Gestión de problemas se toma cierto tiempo para poder encontrar la causa del problema y generar un Know Error y un RFC por lo que se infiere que en la Gestión de problemas actúan los especialistas; de la misma manera en la Gestión de Acceso son personas con cierto nivel de autorización quienes son capaces de poder dar los privilegios correspondientes a los usuarios.

Service Desk es un punto rápido de contacto donde se resuelven incidentes de la manera mas rápida posible, esto nunca lo olviden!!! (lo voy a poner en negrita y de rojo).

help_desk_72dpi

Entonces…. ¿Qué hace Service Desk?

- Resuelve incidentes
- Escalamiento adecuado, no todo debe ser escalado lo ideal es que Service Desk pueda resolver un 70% u 80% de todos los casos.
- Mantener a los usuarios informados del status de su incidente o problema.
- Cumplir el acuerdo de atención del SLA.

Service Desk además cumple un ROL importante, Service Desk es el único punto de contacto para atender servicios, a esto ITIL llama SPOC. Aquí entra un poco de cultura organizacional, aquí unos ejemplos:

- Llama directo al Administrador de Base de Datos, el sabe como solucionar el problema.
- Llama a este chico porque es mi amigo y nos va atender rápido.
- Dame tu numero de anexo para llamarte cualquier cosa.
- ¿Aló Helpdesk? Pásame con el que sepa mas de Outlook.

Estoy seguro que alguna vez han escuchado estas frases,verdad? y ¿como resolver este problema? la solución no están sencilla y tomar la decisión de cambiar esto y no contestar llamadas personalizadas pasa por un cambio en la cultura organizacional y de los usuarios, un cambio gradual es lo ideal; además de un cambio de tecnología también como por ejemplo agregar mas números telefónicos a la central de Service Desk.

No debemos olvidar que no es posible implementar ITIL v3 si no contamos con las herramientas debidas.

¿Por qué es malo que llamen a una persona de IT de manera individual?
Existen una infinidad de respuestas para esta pregunta pero para muestra un botón, cuando llaman directamente a un Administrador de BD o Servidores lo que esta haciendo es distraerlo de sus verdaderas funciones y le resta tiempo; además que estos casos o incidentes no son registrados en la CMDB por lo que no podemos llevar un control cuantitativo de todos los casos atendidos por el Service Desk. ITIL debe ser capas de registrar todo para poder estimar tiempos, costos y mejorar el servicio.

Tipos de Service Desk

Service Desk Local: Es el clásico service desk de una empresa, donde existe un grupo de usuarios locales y un solo centro de servicio.

Service Desk Centralizado: El mejor ejemplo aquí son las organizaciones que prestan servicios de Service Desk a otras organizaciones, por ejemplo las organizaciones que brindan soporte a los Bancos. Aquí existen múltiples usuarios y un solo centro de servicio.

Service Desk Virtual de Servicios Centralizados: Aquí el ejemplo son las grandes empresas de Internet, por ejemplo MySQL Support (La versión Enterprise de MySQL brinda este servicio) tiene diferentes centros de Servicio: uno para Latinoamérica, otro para China, etc etc pero todos son contactados por un único medio, mediante la creación de un ticket mediante su pagina web.

proceso-sd

La imagen superior explica las maneras en como Service Desk recibe solicitudes de atención: correo, vía telefónica, vía web, etc y además no olvidemos que cualquier tipo de servicio, CUALQUIER!!! debe ser recibido por Service Desk.

IMPLEMENTAR UN SERVICE DESK

La implementación no es tan simple como parece, requiere una dedicada planificación y debe responderse las siguientes preguntas:

- ¿Cuáles son las necesidades?
- ¿Cuáles serán sus funciones?
- ¿Que calificaciones profesionales poseerán sus integrantes?
- ¿Qué tipo de Service Desk necesitamos: local, centralizado o virtual?
- ¿Qué herramientas tecnológicas necesitamos?
- ¿Qué métricas determinaran el rendimiento?

El factor humano juega aquí un rol muy importante, el factor humano debe:

- Establecer estrictos protocolos de interacción con el cliente, estándares de comunicación desde el saludo hasta las preguntas de rutina a realizar.
- Informar a los clientes de los beneficios del Service Desk.

Estructura lógica del Service Desk

- Conocer los protocolos de comunicación con el cliente, conoces los cheklists (preguntas de rutina a realizar para determinar la causa del incidente).
- Disponer y conocer las herramientas de software para el registro e interacción con el usuario.
- Conocer cuando hacer un escalado a instancias superiores.
- Tener rápido acceso a la base del conocimiento para ofrecer un mejor servicio a los usuarios.

Indicadores Claves de Rendimiento
La manera de saber si mi Service Desk esta funcionando adecuadamente para por responder las siguientes preguntas:

- ¿Se atiende rápido el teléfono?
- ¿Cumplo con los tiempos acordados en el SLA?
- ¿Cuanto tiempo pasa hasta escalar la llamada a un segundo nivel?
- ¿Cuantos casos escalo a un segundo o tercer nivel?
- ¿Los usuarios reciben consejos de como prevenir incidentes?
- ¿Se atiende el teléfono con educación?

Informes de Gestión
Como en todos los procesos de ITIL, debemos ser capaces de poder tener informes detallados sobre nuestro Service Desk.

- % de incidentes que pueden resolverse sin recurrir a otros niveles de soporte.
- Numero total de llamadas recibidas.
- Tiempo total de resolución y promedios de tiempo de resolución.
- Etc

Factores Críticos de Éxito
Existen factores que determinan el éxito o fracaso de un Service Desk, estos factores son:

- Difícil manera de contactar a Service Desk, si los usuarios encuentran complicado contactar con Service Desk simplemente no verán los beneficios de este y buscaran otro tipo de soporte.
- Si los usuarios tratan de contactar directamente a los especialistas, automáticamente deben ser remitidos al Service Desk.

¿Cuál es el objetivo principal de Service Desk?
Resolver el mayor numero de incidentes, ser la primera línea de defensa de TI de manera que los especialistas puedan concentrarse en su verdadero trabajo.

primer-cuadro

segundo-cuadro

  Existen además diversas políticas de como implementar un Service Desk y depende de las necesidades de la organización y del SLA, por ejemplo en algunas organizaciones como las publicas se tiene un Service Desk con personas especializas y dedicas en brindar ayuda a personas de alto cargo como ministros o embajadores; es decir su único trabajo es brindarles servicio a ellos mientras que otros atienden al resto de usuarios; todo esto depende obviamente de las políticas de la organización.

Hasta aquí llego este post, he tratado de cubrir lo mas que he podido todo el tema sobre Service Desk, además les comparto un video que encontré en Youtube sobre Service Desk, es bastante corto pero resumen muy bien este tema. Saludos a todos y gracias por sus comentarios.

Popularity: 95% [?]

Ha pasado casi un mes desde que escribí mi ultimo post sobre ITIL y si alguno pensó que estaba vagando o simplemente me había aburrido de escribir, déjenme decirles que uno de mis principales defectos (o quizás virtud….) es estar siempre estudiando algo, lo que me resta tiempo para cosas como escribir en mi blog y demás actividades de ocio.

Bueno hoy pienso dar un paso mas para ir concluyendo mis posts sobre ITIL v3; hasta el momento ya he escrito 4 posts y no quiero caer pesado pero les recomiendo leer los posts anteriores para entender todo el contexto de ITIL.

Si quieres darle un review a los post anteriores, aquí lo puedes hacer:

- Introducción a ITIL v3
- Estrategia del Servicio
- Diseño del Servicio
- Transición del Servicio

Habíamos dejado la “acción” en la implementación del servicio (Transición del Servicio – ST), acuérdense que en la ST habíamos visto la gestión del cambio, gestión del activo servicio y configuración, y la gestión del despliegue, ¿lo recuerdan, verdad?. Pues la lógica me indica que después de implementar el servicio en un cliente viene algo que cae por su propio peso…. MANTENER EL SERVICIO SIEMPRE FUNCIONANDO.

monitoreo

¿Acaso existe un sistema de TI que funcione completamente solo y sin necesidad de algún mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos requerimientos por parte de los usuarios, los DBA siempre tienen que monitorear que sus BDs estén funcionando, los sysadmin revisar que todo el sistema corporativo este funcionando y así podría pasarme todo el día diciendo que este trabajo nunca tiene fin, por eso en ITIL v3 existe algo que se llama MEJORA CONTINUA que será el tema del siguiente y ultimo post.

Con esas cuantas líneas arriba he tratado de resumir lo que hace la Operación del Servicio y que entramos a analizar en este mismo instante:

Definición, metas y objetivos
SO (Service Operation), conduce, gestiona y controla las operaciones del día a día de los procesos, con la finalidad de tener los servicios estables, registrar incidentes, registrar problemas y sugerir el uso de nuevos procesos. Seamos sinceros …. muchas personas desmerecen este tipo de trabajo, no? pero por el contrario este trabajo tiene una importancia estrategia importante! porque estas son las personas que dan la cara frente al usuario, son los que dicen: “Buenos días, el área de TI le habla; ¿en que puedo ayudarlo?” y nunca debemos olvidar que el área de TI brinda servicios a los clientes y son estos quienes perciben el valor del servicio.

impacto

Cuando hablamos de gente que esta constantemente monitoreando los servicios, atendiendo llamadas y dando soluciones temporales, hablamos de nuevos conceptos como: impacto, urgencia y prioridad. Imaginemos….. llama un usuario de logística indicando que no puede abrir un archivo PDF y llama el director general indicando que no le funciona el outlook, ¿a quien se atiende primero? ¿al que llamo primero?, pues…. eso depende de muchos factores como la cantidad de gente con la que se cuente, la cantidad de recursos y de tiempo.

Terminología: En este tema existen muchos términos nuevos y definiciones muy técnicas así que me gustaría explicarlo mejor con un ejemplo para que quede bien claro:

Se tiene una aplicación llamada “ABC” programada en Java que utiliza una BD Oracle, esta aplicación es accedida mediante un browser por los clientes quienes agregan información de manera diaria.
Cierto día, los chicos de SO reciben un correo de sistema CACTI (sistema que monitorea el ancho de banda de la red) indicando que el consumo del ancho de banda de la red se ha incrementando en un 40% desde las 12pm hasta las 4pm. A los 2 días de recibido este correo, llega otro correo del sistema CACTI indicando que el disco duro del servidor de BD ha pasado el 80% de su capacidad y que se recomienda liberar espacio. Al tercer día (y justo fin de mes) llama un cliente indicando que el sistema “ABC” no funciona y que no puede adjuntar información y que necesita hacerlo lo antes posible porque tiene que terminar su trabajo de fin de mes, a los 10 minutos de esta llamada se reciben 5 nuevas llamadas de otros usuarios con el mismo inconveniente.

cacti_overview

De este pequeña historia que es totalmente real, tenemos:

Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algún usuario estaba agregando bastante información)
Alerta: Uso del disco duro en un 80%
Incidente: Primera llamada del usuario que no puede adjuntar archivos
Problema: 5 clientes que no pueden usar el sistema el fin de mes
Workaround (Solución temporal): Montar nuevo disco duro para aumentar el espacio en disco
KnowError (Error conocido-KE): Este error se ha presentado con anterioridad y el procedimiento de solución y causa del problema esta documentada.
Reactivo: Personas que actúan solo frente a un aviso o problema.
Proactivo: Personas que están en búsqueda de la mejora continua

[More]

Popularity: 43% [?]

Cuarto post sobre ITIL v3, en donde hablaremos sobre la transición del servicio. Para poder entender correctamente este post y relacionar correctamente todos los temas deberíamos haber leído antes: Introducción a ITIL v3, Estrategia del Servicio (SE) y Diseño del Servicio (SD).

homersapien-1024x768 ITIL se baja en algo tan simple como la lógica!!! no hay nada misterioso o que nunca hayamos hecho antes los que estamos metidos en el mundo de TI, analicemos un poco; primero analizamos la estrategia para saber como podemos enfrentar una solución de TI, luego diseñamos los pasos a seguir es decir los procedimientos y ahora lo que debe continuar es IMPLEMENTAR EL SERVICIO, es decir la TRANSICION de lo pensado hacia sistemas tangibles.

Entonces Service Transition (ST) se encarga de coordinar los procesos y funciones para empaquetar, construir, probar y desplegar una versión del servicio según lo acordado en el SLA, con el objetivo de llevar un control  e información de los cambios realizados, mejorar el impacto sobre el ambiente de producción e incrementar la satisfacción del cliente durante el proceso de transición.

Algunos conceptos y definiciones de ITIL v3

  • Ítem de configuración (CI): Es todo activo, servicio, componente de servicio o cualquier ítem que es o esta bajo el control de la gestión de la configuración, aunque el termino parece sencillo el examen de certificación de ITIL trae siempre preguntas sobre esta definición.
  • Sistema de congestión de la configuración (CMS): Gestiona todos los CIs.
  • Definitive Media Library (DML): Biblioteca segura que almacena y protege las versiones autorizadas y definitivas de todos los CIs.
  • Unidad de liberación (Release Unit): Porción de un servicio o infraestructura de TI que es liberada o desplegada según las políticas de la organización.

Como ya habíamos comentado en las primeras líneas, la “Transición del Servicio” ejecuta y plasma el diseño del servicio en un servicio táctil y utilizable; sin embargo no es están simple como “hacerlo o ejecutarlo” sino que hay toda una gestión y procesos detrás de estos, estos procesos son:

  • Gestión del Cambio
  • Gestión del Activo servicio y la configuración (SACM)
  • Gestión de la liberación y el despliegue

GESTION DEL CAMBIO

gestion cambio comic

La gestión del cambio se asegura que todos los cambios sean registrados, evaluados, autorizados, priorizados, planeados, probados, implementados, documentados y revisados de manera controlada, para que el impacto en los usuarios sea confortable. 

Conceptos en la gestión del cambio

  • Políticas y estándares: reglas que proveen una cultura y ambiente que soporta el cambio. Por ejemplo una política de cambio es que todo cambio debe ser probado por el periodo de 15 días hábiles como mínimo.
  • Requerimientos de cumplimiento regulatorio: Este se aplica a disposiciones legales, por ejemplo si el estado decide aplicar un aumento al IGV, el sistema informático debe cambiar, a esto se le llame un cumplimiento regulatorio.
  • Pruebas y procedimientos de post evaluación: La gestión encargada de evaluar que el cambio ha sido implementado con éxito es la GESTION DEL CAMBIO (pregunta de certificación)
  • CAB (Comité de Cambio) y ECAB (comité de cambio de emergencia)
  • Stakeholders: Involucrados en la planeación y preparación del cambio, aconsejan cronograma de cambios.

¿Que es para ITIL un cambio?

  • Un cambio en el estado de un CI
  • Un cambio de un CI en las relaciones con otro CI
  • UN NUEVO CI (pregunta de certificación)
  • Un nuevo propietario o cambio de ubicación de un CI

[More]

Popularity: 17% [?]

11 Aunque siempre tengo mil cosas por hacer me he dado un tiempo hoy domingo por la noche para escribir EL TERCER POST DE ITIL, para aquellos que han llegado a este post sin antes haber leído los dos primeros post  sobre ITIL les recomiendo leer el primer post y el segundo post.

Habíamos explicado en el post anterior sobre Service Strategy (Estrategia del Servicio) que se encargaba primordialmente de analizar lo que le vamos a brindar al cliente (Gestión del Portafolio del Servicio), cuanto demanda el servicio brindado (Gestión Financiera) y analizar a cuantos clientes se provee el servicio (Gestión de la demanda); pues bien después de haber analizado el rubro de la organización y de decidir ¿Cómo? le vamos a brindar el servicio ahora toca diseñar el servicio, es aquí donde entra en acción: Service Design (SD).

Definición
Service Design (SD) diseña los servicios de TI que se va a brindar, esto incluye: arquitecturas, procesos, políticas y documentación; para cubrir con el actual SLA y las futuras necesidades (Integración con el negocio), es decir y para entenderlo mas claro aun, lo que hace SD es trasladar los planes estratégicos y objetivos que se decidió en SS, hacia la creación de diseños y especificaciones (procesos y políticas) que luego serán ejecutados en las fases de Transición y Operaciones (que serán los 2 siguientes posts).

Vamos a poner un ejemplo y para seguir una misma idea voy a usar el ejemplo colocado en el post de Service Stategy, el ejemplo trata de una organización que necesita almacenar información de sus clientes y nosotros como expertos en TI mediante el Service Strategy hemos decidido brindar los siguientes servicios: un SGBD (Sist. Gestor de BD) y un sistema web en la nube; después de haber tomado esta decisión entra SD y su trabajo es:

  • Crear políticas: Por ejemplo, el backup de la BD se hace al medio día y a la media noche y se almacena en un lugar externo al de la empresa (obviamente se deben crear mas políticas).
  • Diseño de arquitectura
  • Apoyar al diseño del portafolio: SD apoya a SS en la creación del portafolio, imagínense que el jefe de IT que esta negociando el servicio que va a brindar (SS) y el cliente solicita un servicio bajo Red Hat Linux para su BD y aplicación, entonces el jefe de IT acepta pero luego se da cuenta que ellos no cuentan con personas especialistas en Red Hat, es obvio que esto no puede pasar, por eso SD  apoya en el diseño del portafolio advirtiendo que no se puede brindar servicios de Linux debido a que no se cuenta con personal capacitado para esta actividad.
  • Tecnología efectiva: ¿Qué usamos? un switch CISCO o un switch no administrable.
  • Diseño de proceso y sus métricas: El proceso son los pasos detallados para implementar el servicio, por ejemplo:
    • Paso 1: Instalar el SO bajo ciertas caracterices
    • Paso 2: Instalar JAVA o PHP de la siguiente manera
    • Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parámetros
    • Paso 4: ……..

¿Y todo esto para qué es necesario?

  • Obviamente tener todo organizado tiene sus ventajas económicas y esto se refleja en el TCO (Costo total de la propiedad), por ejemplo el TCO de una computadora es: Hardware + Software + Servicio recibido.
  • Tener documentado paso por paso MEJORA LA CALIDAD DEL SERVICIO, MEJORA LA CONSISTENCIA DEL SERVICIO y MEJORA EL GOBIERNO CORPORATIVO.

Actividades de SD

  1. Gestión del Portafolio del Servicio
  2. Identificación de los requerimientos del negocio, definición y diseño del servicio
  3. Diseño de la arquitectura tecnológica
  4. Diseño del proceso
  5. Diseño de las métricas

Voy a explicar cada punto:

Gestión del Portafolio del Servicio (SPM): El dueño de este proceso no es SD sino SS, es decir SS aprueba el portafolio de servicio que se va a brindar al cliente pero es obvio que necesita del apoyo de SD para conocer precios, fortalezas, oportunidades, debilidades y amenazas del servicio.

1

Identificación de los requerimientos del negocio, definición y diseño del servicio: Para poder apoyar a la SPM primero necesitamos saber que requiere el negocio con exactitud y recién sabiendo que quiere el cliente podemos diseñar el servicio, evaluar las alternativas de diseño y conocer los costos que este implica.

Diseño de la arquitectura tecnológica: Hace referencia al diseño arquitectónico y la arquitectura empresarial.

[More]

Popularity: 12% [?]