Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Procesos ITIL

Roles y Responsabilidades
by

Eduardo Lobos

on 9 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Procesos ITIL

Roles y Responsabilidades Subgerencia TI
Gerencia de Sistemas Grupo GTD * Flujo de Actividades Monitoreo Llamadas Telefónicas Correo electrónico 01
Identificación de Incidente 02
El registro del Incidente 03
Categorización del
Incidente 04
Requerimiento 05
Priorización del
Incidente 06
Diagnóstico
Inicial 08
Requerimiento
Jerárquico? Proceso de
Gestión de
Incidentes Proceso de
Gestión de
Cambios Proceso de
Gestión de
Requerimientos Correo electrónico 07
Escalamiento
Funcional? 08
Escalamiento
Jerárquico? 09
Investigación & Diagnóstico 10
Resolución & Recuperación 11
Cierre del
Incidente Fin Los Incidentes pueden ser identificados por varias Fuentes: usuario/Cliente, Torres de Ingeniería, monitoreo de servicios TI claves y componentes de servicio. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R/I R R/C Todo lo relacionado a la información pertinente a la naturaleza del incidente debe ser registrado de manera que se mantenga un registro histórico los más completo posible. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R I C/I Los Incidentes son categorizados (del CI) con la clasificación más exacta del contacto. Esto ayudará más tarde con los informes, análisis de tendencia y cruce de Incidentes a Problemas, errores conocidos y soluciones temporales validadas. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R C C/I Cumplir
Requerimientos Los Requerimientos son algunas veces registrados incorrectamente como Incidentes. Este punto de decisión es usado para identificar un requerimiento que debería ser traspasado al Proceso de Requerimientos. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R R C/I Los Incidentes son priorizados evaluando el impacto y la urgencia. La Prioridad es usada para determinar cómo/cuando el incidente será manejado por el personal de soporte y apoyados por la herramienta Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A C/I R R/C/I C/I Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R I C/I El Help Desk realiza el diagnóstico inicial para todo los Incidentes para los cuales los Cliente han contactado a esta. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A I R C/I C/I Tan pronto como se ponga de manifiesto que el Help Desk no puede resolver el Incidente, este deberá ser escalado al equipo de soporte apropiado. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A/I C/I R C/I I Los Incidentes urgentes o de Alto impacto pueden necesitar ser escalados a la gerencia, aun cuando sea a través de una notificación. Los Incidentes también pueden ser escalados a la gerencia si ha pasado mucho tiempo o de acuerdo a los procedimientos jerárquicos establecidos. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A/I C/I I R/C/I C/I La Investigación y Diagnostico puede ser un proceso interactivo, partiendo con diferentes grupos de soporte especialistas y descartando las posibles causas. Esto puede involucrar grupos de soporte multi-sitios y personal de soporte de diferentes proveedores. Esto requiere rigurosidad, disciplina y un amplio registro de las acciones tomadas con los resolutores correspondientes. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A/I C/I I R C/I Después de la ejecución satisfactoria de la resolución o alguna actividad mitigadora, las acciones de recuperación de servicio pueden ser llevadas a cabo, por el personal especialista (Soporte de segundo o tercer nivel). Todos los eventos y acciones durante las actividades de resolución y de recuperación deben ser documentados en el registro del Incidente para que exista un histórico. Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A C/I R I C/I El Help Desk debe asegurar que:
Los Detalles de las acciones tomadas para resolver el incidente son concisas y entendibles.
La Clasificación debe estar completa y exacta de acuerdo a la causa, por lo cual, si es preciso reclasificar esto se debe hacer.
La Resolución o Acción es informada al cliente (vía correo electrónico, por llamada telefónica, SMS y otros), el cual la debe evaluar y determinar su conformidad
Todos estos detalles aplicables a estas fases del control de Incidentes son registrados tal que:
El cliente está satisfecho
El tiempo consumido en el incidente está registrado
La fecha y hora de cierre queden registrados Procedimiento de escalamiento jerárquico Escalamiento funcional 2/3 12
Propiedad, Monitoreo, Seguimiento, y Comunicación El Help Desk es responsable de la propiedad y revisión de la resolución de todos los Incidentes pendientes, cualquiera sea la fuente inicial:

Monitoreo regular de todos los Incidentes por estado, progreso hacia la resolución y cumplimiento de niveles de servicio
Se debe tener en cuenta que el Incidente que se traspasa entre diferentes grupos de soporte pueda provocar una disputa entre los grupos de soporte. En casos extremos un Incidente puede ser enviado paralelamente a Gestión de Problema.
Dar prioridad al monitoreo de los Incidentes abiertos de Alto Impacto
Mantener informado del avance en la resolución del incidente a los Clientes afectados
Verificar Incidentes similares/relacionados/patrones para que se tomen las acciones acordadas Dueño del Proceso
Incidentes Gestor de
Incidentes Help Desk Torre de
Ingeniería Cliente/Usuario A/I R/C/I R/I C/I I *( Flujo de Actividades 01
Registro RFC 02
Revisión de RFC 03
Evaluar y Valorizar el Cambio 04
Autorizar el
Cambio 05
Plan de
Actualizaciones 06
Coordinación de la Implementación del Cambio 07
Revisar y Cerrar
RFC Fin La La información de la Solicitud de Cambio (RFC) se utiliza para crear un registro de cambio y se debe asignar un número de identificación único (en orden cronológico). Parte de la información se registra cuando se inicia el registro y algunos se pueden añadir o actualizar a través del ciclo de vida del cambio. Aunque puede haber diferentes tipos de registros de cambio, con distintos conjuntos de atributos , se recomienda siempre que sea posible hacer una normalización de estos . Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A I Cumplir
Requerimientos Post Implementation Review Cambio de Configuración y actualización de CMS Solicitante R/C/I Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A R Solicitante I El Gestor de Cambios filtra y revisa la Solicitud de Cambio (RFC) de acuerdo con las políticas determinadas por la organización . Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A R Solicitante I El Gestor de Cambios se asegurará de que exista una técnica de evaluación de impacto y de riesgo para el negocio relativo a la solicitud de cambio. También el Gestor de Cambios se asegura de la participación de los actores necesarios para evaluar el cambio. Todos los miembros con autoridad sobre el Cambio deben evaluar basados en el impacto, urgencia, riesgo, beneficios y costos. Adicionalmente, los miembros con autoridad sobre el Cambio deben de revisar aspectos de planificación, programación y vuelta atrás.
La prioridad del cambio debe establecer el orden en que estos son presentados a las autoridades correspondientes para su consideración de ser cursadas o no. R/C/I Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A R Solicitante R R/C/I Para obtener la autorización formal de un cambio. Primero, éste debe ser
presentado en un formulario, por una persona o grupo de personas.
Los niveles de autorización para un determinado tipo de cambio deben ser juzgados por el tipo, tamaño o el riesgo de ese cambio. Cualquier autorización o rechazo de decisiones deben ser comunicadas a todas las partes interesadas, en particular, para el iniciador de la RFC. Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A I Solicitante R/I R/I Las modificaciones a las solicitudes de cambios se completarán tras la autorización del cambio y se comunicarán a todas las partes interesadas, incluidos los equipos técnicos encargados de construir el cambio. El cambio está previsto en un Calendario de Cambios (FSC). Además, los planes para cualquier proyecto que provoque o pueda provocar la interrupción de un servicio se deberán actualizar y podrán ser comunicados oportunamente a los involucrados (internos o Clientes). Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A I R/C/I I Los RFC autorizados deberán ser transmitidos a los grupos técnicos para construir los cambios. Gestión de Cambio tiene una función de supervisión para garantizar que los procedimientos de recuperación se preparan con antelación y son documentados, además de que todos los cambios son completamente probados (cuando sea posible) de modo que la aplicación del cambio tenga el menor impacto en el servicio. El Gestor de Cambios tiene la responsabilidad de garantizar que los cambios se apliquen según lo previsto. Al término de la ejecución del cambio, los resultados deben ser reportados al Gestor de Cambios para su evaluación y luego informados como un "cambio” a las partes interesadas. La revisión también debe incluir cualquier incidente que pueda surgir como consecuencia de los cambios.
Una Revisión del Cambio (Revisión Post Implementación) debe llevarse a cabo para confirmar que el cambio ha alcanzado sus objetivos, que el promotor y las partes interesadas están conformes con los resultados y que no ha habido efectos secundarios inesperados. En caso de que un cambio no haya logrado sus objetivos, el Gestor de Cambios (y, posiblemente, el CAB) deben decidir qué acción se requiere de acuerdo al seguimiento .
Si la revisión es satisfactoria, la RFC debe cerrarse formalmente en el sistema de registro.
Además, se podrán incluir evidencias comprobables (fotos, print-screen, log’s u otros)
cuando sean pertinentes. Dueño del Proceso Gestor del
Proceso Miembros del
CAB/ECAB y
Aprobadores A R I I Solicitante Solicitante *( Flujo de Actividades Desde
Interfaz Web Llamada
Telefónica Usuario 01
Presentación del Requerimiento 02
El registro del Requerimiento 03
Categorización y Priorización del Requerimiento 04
Cumplimiento del Requerimiento 05
Cierre del
Requerimiento Fin Gestión de
Incidente / Cambio 06
Propiedad, Monitoreo, Seguimiento y Comunicación Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A I I Solicitante
/ Usuario R/I R/C/I La llegada de un Requerimiento al proceso ó desde otros procesos se determina a través de una actividad por medio del canal pre-establecido para este fin (ej.: una herramienta web, el envío de un e-mail).
Todos los Requerimientos se canalizan a través del Help Desk.
El personal de TI puede tener interfaces para la herramienta de Requerimiento para la presentación interna, sin embargo, es importante que todos los Requerimientos pasen a través del Help Desk. Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A I R/I R/C/I R/C/I Solicitante /
Usuario El Help Desk o el Agente designado para los Requerimientos, o algún medio automatizado, registrará los Requerimientos de servicio. La autenticación de usuarios / clientes se regirán por las políticas de seguridad y guías de procedimiento definidas al respecto. Todos los Requerimientos deben ser atendidos. Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A I R/C/I C/I C/I Solicitante /
Usuario Todos los Requerimientos se validan y se evalúa su alcance en el proceso de Gestión de Requerimientos.
Los Requerimientos que se consideran fuera del alcance, se pasan al proceso adecuado como Incidentes, Cambios o Niveles de Servicio para su acción futura.
Los Requerimientos se priorizan según el modelo de asignación de prioridades y de su categoría, lo que es acordado con el Usuario/Cliente. Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A C/I C/I I R/I Solicitante /
Usuario De acuerdo con las políticas y procedimientos del Proceso de Gestión de Requerimientos se pasan al personal designado para su cumplimiento. Se debe proporcionar el tiempo suficiente para evaluar y asignar los recursos para la resolución de los requerimientos a través de las correspondientes áreas de soporte del Grupo GTD. Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A C/I R C/I C/I Solicitante /
Usuario La notificación de cierre del requerimiento se hará a través del Help Desk, una vez que se hayan cumplido las actividades y plazos programados y acordados con el Usuario/Cliente, para la resolución del requerimiento. Dueño del Proceso de Requerimientos Gestor del Proceso
de Requerimientos Coordinador de Requerimientos
Jefe Help Desk Torres A R R/I I C/I Solicitante /
Usuario La propiedad de cada Requerimiento de servicio pertenece al Help Desk, independientemente de cuándo dicho requerimiento es resuelto.
Utilizando las herramientas disponibles todos los Requerimientos deben pasar por lo siguiente:
Monitoreo para asegurar que se cumplen las actividades establecidas por el proceso para el ciclo de vida del requerimiento.
Seguimiento para asegurar que todas las acciones se registren con el nivel adecuado de detalle para que el Help Desk pueda dar cuenta de lo que ha ocurrido o está ocurriendo durante la vida de un Requerimiento.
La comunicación se realiza entre el Help Desk con el cliente/usuario y con el personal de TI, cuando sea necesario y se indica de acuerdo con las políticas y procedimientos. muchas
gracias ! Subgerencia TI
Gerencia de Sistemas Grupo GTD
Santiago, Septiembre 2012 *Procesos ITIL
Full transcript