Source: http://docplayer.es/1121151-Serie-articulos-sobre-gestion-de-it-y-calidad-introduccion-a-itil-segunda-parte.html
Timestamp: 2017-05-24 17:58:16+00:00

Document:
Serie Artículos sobre Gestión de IT y Calidad. INTRODUCCIÓN A ITIL Segunda Parte - PDF
Download "Serie Artículos sobre Gestión de IT y Calidad. INTRODUCCIÓN A ITIL Segunda Parte"
Ernesto Calderón Contreras
1 Serie Artículos sobre Gestión de IT y Calidad INTRODUCCIÓN A ITIL Segunda Parte 12 Introducción a ITIL (Segunda Parte) Autor: Dr. Norberto Figuerola (PMP) Contador Público y Licenciado en Administración (U.B.A.) Master in Project Management (George Washington University) ITIL Consultant e ISO Auditor En esta segunda parte del artículo veremos un detalle de los principales grupos de gestión de servicios de ITIL correspondientes a los procesos de Soporte del Servicio, reflejados en la parte izquierda del gráfico, junto con el Service Desk : Change Management Release Incident Service Management Management Support Service Level Management Financial Availability Service Management Management Delivery Configuration Management Problem Management IT Service Continuity Management Capacity Management Service Desk Service Desk Los objetivos de la función de Service Desk son: Proveer un único contacto con los usuarios Facilitar la restauración de un servicio normal de operaciones con un impacto mínimo posible hacia los negocios del usuario dentro de un nivel conveniente y respetando las prioridades del negocio Mejorar los conocimientos al usuario de los servicios disponibles y de los trabajos prácticos Identificar las deficiencias en los usuarios y su entrenamiento que o bien impactaron negativamente en el uso de los servicios, o bien, creando una carga de trabajo innecesaria para los empleados Implementar un programa educacional que resuelve las deficiencias identificadas para los usuarios, clientes y empleados del mismo Las funciones del Service Desk más comunes incluyen: Recibir llamadas, primer enlace con el cliente Grabar y seguir los incidentes y las quejas Mantener a los clientes informados sobre la demanda y su evolución Hacer una valoración inicial de la demanda, intentando resolverlas o remitirlas a otra persona, que puede atenderlas, basado en un nivel de servicio conveniente 23 Monitorear e intensificar los procedimientos relativos a la apropiada SLA (Acuerdo de nivel de servicio) Administrar el ciclo de vida de la demanda, incluyendo el cierre y la verificación Planear una comunicación y un cambio de niveles de servicio a corto plazo hacia los clientes Coordinar los segundos enlaces y apoyo de terceros Proveer la gestión de información y recomendaciones para el mejoramiento del servicio Destacar las necesidades del cliente especialmente en la educación y en el entrenamiento Cerrar los incidentes y confirmación con los clientes Contribuir a la identificación del problema Proporcionar confirmación a los Clientes y los Usuarios de que su solicitud ha sido aceptada y de su progreso, es uno de los roles más importantes del Service Desk. A pesar de ello, muy pocas organizaciones tienen los recursos de personal para centrarse en esto y mantener esta actividad. El uso de tecnologías, tal como , asiste con esta tarea. Sin embargo, el reto real es el de crear un vínculo personalizado con los clientes aunque sea por comunicación electrónica. Ya que la Gestión de Servicio de IT está orientada en torno a la entrega de niveles predeterminados de servicio a los usuarios finales, es sensato instalar una organización cuyos directivos fundamentales sean: Dar soporte a los usuarios a medida que requieran ayuda para hacer uso de los servicios presentes en el entorno de IT Monitorear el entorno de IT para el cumplimiento de estos niveles predeterminados de servicio y escalar las incidencias en la entrega de servicios de la manera adecuada cuando surjan El Service Desk se ha percibido tradicionalmente como un conjunto de individuos que reciben todas las consultas e incidentes y de quienes, se espera, tengan la destreza técnica adecuada para contestar prácticamente cualquier pregunta o queja. Tal y como se representa en ITIL, esta disciplina de Service Desk ha evolucionado hasta tal punto que puede ser ejecutado con un alto grado de eficacia, conseguido gracias a varios factores: La actitud de servicio está instalada en la documentación de la disciplina, habilitando a los empleados del Service Desk para centrarse no sólo en resolver este asunto sino más en restaurar inmediatamente el servicio para este usuario. Procesos rigurosos se definen para facilitar las actividades de los empleados del Service Desk. Estratégicamente, para los Clientes el Service Desk es probablemente la función más importante de una organización. Para muchos, el Service Desk es la única ventana al nivel de servicio y profesionalidad ofrecida por la organización entera o un departamento. Esto hace entrega del más importante componente de servicio de Satisfacción y Percepción del Cliente. De modo interno a la función de IT, el Service Desk representa los intereses del cliente al equipo de servicio. Cuando un servicio se ha interrumpido, el objetivo de algunos procesos es restaurar el servicio. El Service Desk es la organización que facilita los otros procesos. Esto significa que el Service Desk es responsable de un evento de servicio de principio a final. Mientras que otras funciones (tal como soporte de segunda y tercera línea) asistirán en la resolución, el Service Desk retiene control administrativo de la 34 incidencia. Otro objetivo es ser el Único Punto de Contacto ( SPOC ) entre los Clientes, Usuarios, servicios de IT y organizaciones de soporte externas para todas las necesidades, preguntas, quejas, comentarios y cambios relacionados con IT El Service Desk debería soportar las actividades de negocio al entender IT en un contexto de negocio y sugerir mejoras de provisión de servicio. El Service Desk genera informes de gestión El Service Desk se comunicará con los clientes acerca de sus llamadas de servicio. El Service Desk promoverá sus ventajas a toda la organización El Service Desk no está programado con la tarea de encontrar la causa original de una interrupción de servicio; esa responsabilidad cae a la Gestión de Problemas. Tipos de Service Desk Centro Telefónico (Call Center) El énfasis de un Centro Telefónico está en manejar grandes volúmenes de transacciones originadas por teléfono. Normalmente, un centro telefónico no reaccionará a esas transacciones sino que sólo las registrará y las referirá a otras partes de la organización. Servicio al cliente (Help Desk) El propósito primario es gestionar, coordinar y resolver Incidencias, lo antes posible y asegurarse de que ninguna solicitud se pierda, olvide o ignore. Los vínculos con la Gestión de Configuración y las herramientas de conocimiento se utilizan generalmente para soportar las tecnologías. El Service Desk normalmente no maneja más que incidencias. Service Desk El Service Desk extiende el campo de servicios permitiendo que se integren procesos de negocio en la infraestructura de Gestión de Servicio. No sólo maneja Incidencias, Problemas y cuestiones, pero también proporciona un nexo común para otras actividades tal como solicitudes de Cambio de los clientes, contratos de mantenimiento, licencias de software, Gestión de Nivel de Servicio, Gestión de Configuración, Gestión de Disponibilidad, Gestión Financiera de los Servicios de IT y Gestión de Continuidad de Servicio de IT. Muchos Call Centers y Help Desks naturalmente evolucionan hasta convertirse en Service Desks para mejorar y extender su servicio global a los Clientes y el negocio. Las tres funciones comparten características comunes: representan el proveedor de servicio al Cliente y al Usuario (interno o externo), operan con el principio de que la satisfacción y percepción del cliente son críticos, dependen de mezclar personas, procesos y tecnología para poder entregar un servicio de negocio. La interacción del Cliente ya no se limita tan solo al contacto telefónico y personal. El servicio puede realzarse enormemente y ser extendido al Cliente, Usuarios y empleados de soporte expandiendo los métodos de registrar, actualizar y consultar las solicitudes. Esto podría ser: utilizando , fax, lnternet/lntranet para oficinas remotas, etc. Estos métodos son mejor explotados para actividades que no son vitales para el negocio, que incluye el registro de Incidencias o solicitudes nourgentes, tales como: Adquisición de productos Consultas de aplicación 45 Solicitudes para traslado, instalaciones, mejoras y actualizaciones de equipamiento Solicitudes de insumos El uso de inversión basada en formularios aumenta la integridad de los datos sometidos y asiste con la asignación del especialista de soporte, equipo o departamento más adecuado. La herramienta del Service Desk debería automáticamente proporcionar al Cliente o al Usuario un recibo con un número exclusivo de referencia, que también permite la consulta sobre la marcha del progreso de la solicitud. Proporcionar a los Usuarios y Clientes confirmación de que su solicitud ha sido aceptada y de su progreso, es uno de los roles más importante del Service Desk. Aún así muy pocas organizaciones tienen los recursos de Personal para centrarse y mantener esta actividad. El reto real es crear un vínculo personalizado con los clientes, aunque sea mediante la comunicación electrónica. Estructuras de Service Desk Service Desk Local o Distribuído Tradicionalmente, las organizaciones han creado desks de soporte locales para cumplir las necesidades locales del negocio. Si la organización está manteniendo varios desks de soporte local, es importante introducir estándares operacionales. Consideraciones para implementar una estructura de Service Desk Local incluyen: Establecer procesos comunes para todas las localidades y, de ser posible, procedimientos comunes Hacer que se conozcan y sean disponibles a otros Service Desks, Asegurar compatibilidad de hardware, software e infraestructura de red Usar los mismos procesos de escalamiento, y los mismos códigos de impacto, severidad, prioridad y status en todas las localidades Usar medidas de informes de gestión común Usar una base de datos compartida (lógica) comúnmente De estar disponible, establecer la posibilidad de pasar o escalar solicitudes entre Service Desks, preferiblemente de forma automática. Service Desk Centralizado El Service Desk Local es práctico pero por sus múltiples localizaciones puede duplicar habilidades y recursos y eso es costoso. Por lo tanto, es bueno establecer un Service Desk central si el tipo de soporte lo permite y si es técnicamente posible. En esta opción, todas las solicitudes de servicio están registradas en una localización física central. Si la organización tiene localizaciones múltiples, tener un servicio de soporte central tiene ventajas mayores para el negocio, incluidos: Costos operacionales reducidos Visión global de gestión consolidada Uso mejorado de recursos disponibles Claro que otras partes de los servicios siguen teniendo que ser soportados en cada localización. Por ello, se ven muchas organizaciones con Desks Centrales y Locales combinados. Service Desk Virtual Hasta un punto, la situación física del Service Desk y los servicios asociados son inmateriales, debido a los avances en redes y telecomunicaciones. El Service Desk Virtual puede situarse y ser accedido desde cualquier lugar del mundo. Si la organización tiene múltiples localizaciones, un Service Desk de soporte global tiene ventajas mayores para el negocio, incluidas: 56 Costos operacionales reducidos El rango para la visión global de gestión consolidada Uso mejorado de recursos disponibles. Sin embargo, la restricción operacional primordial del Desk Virtual es la necesidad de la presencia física de un especialista o un ingeniero de reemplazo. Establecer un Service Desk no es fácil. Por lo tanto, aquí hay algunos consejos: Establecer que la necesidad del negocio está claramente identificada y entendida. Sin esto, es muy difícil implementar un desk. Necesitamos saber qué tenemos que soportar. Asegurarnos que el compromiso, presupuesto y recursos de la dirección están disponibles. Todo tipo de procesos y procedimientos deben ser implementados, las herramientas deben ser despachadas y las responsabilidades cambian. Sin el compromiso de la dirección, esto no se va a realizar. Asegurar que la solución propuesta está en línea con la estrategia de soporte de servicio. Definir objetivos claros y que se puedan entregar Empezar de modo sencillo; no intente hacer todo de golpe; adoptar un enfoque de fases Involucrar /consultar a los clientes y usuarios finales. Hable con ellos de expectativas, objetivos y tareas Venda las ventajas al personal de soporte. Dígales que un solo punto de contacto también les beneficia. Tendrán más tiempo para hacer el trabajo de verdad. Forme al personal de IT para ser personal de servicio. La comunicación es uno de los factores de éxito más críticos. El Service Desk no debe estar centrado de modo técnico sino orientado al servicio. Eduque a los clientes y usuarios en el uso del nuevo servicio y sus beneficios. Anuncie y venda su servicio. Al montar un Service Desk, tenga en cuenta las siguientes guías: De ser posible, tener un local apartado de la zona de soporte principal con: Un área agradable y confortable para Clientes y Personal del Service Desk Un entorno de bajo nivel de ruido Privacidad Instalar una biblioteca de todos sus productos, documentación de hardware y software y material de referencia que utilizan los clientes Asegurar un Catálogo de Servicio actualizado disponible a todas horas Instalar facilidades telefónicas y de conferencia Proveer espacio de mesas y asientos para discusiones de mesa redonda- Publicar a la base de Clientes la localización de la unidad y sus horarios operacionales Al considerar el nivel de servicio y el entorno proporcionados, es bueno preguntarse Es así cómo me gustaría que me trataran? 67 Gestión de Incidencias Ya que la Gestión de Servicio de IT está orientada en torno a la entrega de niveles predeterminados de servicio a los usuarios finales, es sensato instalar una gestión cuyas directivas sean: Monitorear el entorno de IT para el cumplimiento de esos niveles de servicio predeterminados y escalar adecuadamente incidentes en la entrega de servicio cuando surjan. La función de la Gestión de Incidencia tiene la responsabilidad de resolver esas incidencias cuánto antes, para habilitar el servicio y si la incidencia es crónica informar a Gestión de Problemas. Incidencia es cualquier evento que no es parte de la operación estándar de un servicio y que puede causar una interrupción o disminución del mismo (incluye peticiones de servicios). La importancia del proceso de Gestión de incidencia se puede resumir como sigue: cuando un usuario experimenta un incidente el proceso de Gestión de Incidencias asegurará que el servicio del usuario estará disponible de nuevo tan pronto como sea posible. El objetivo principal de la Gestión de Incidencias es: Resolver el asunto de servicio tan pronto como sea posible, al menos dentro del tiempo objetivo documentado en el acuerdo de Nivel de Servicio Mantener la comunicación viva entre la organización de IT y su cliente sobre el status con relación al asunto de servicio (p.ej. a quien se escaló, tiempo estimado de resolución) Evaluar una incidencia para determinar si es probable que vuelva a ocurrir o si es síntoma de un problema crónico. Si lo es, informar a un Director de Problemas al respecto Actividades de la gestión de incidentes: Detección y registro del incidente Clasificación y apoyo inicial Investigación y diagnóstico Resolución Cierre del incidente Monitoreo, seguimiento y comunicación Un administrador o encargado de incidentes tiene responsabilidades sobre: Llevar la eficiencia y la efectividad de los procesos Generar el manejo de los informes y métricas Gestionar el trabajo de los empleados del soporte de incidentes Monitorear la efectividad del manejo de incidentes y de las recomendaciones principales para su resolución Desarrollar y mantener el sistema de gestión de incidentes Las responsabilidades en primera línea (Service Desk) incluyen: El registro de incidentes Hacer un seguimiento de las demandas para apoyar los grupos cuando entren incidentes y no están completadas Soporte inicial y su correspondiente clasificación Propiedad, monitoreo, seguimiento y comunicación Resolución y restablecimiento Pasar os incidentes no asignados al soporte de segunda línea Cierre de los incidentes 78 Soporte en segunda línea (grupos especiales que no deben estar dentro del grupo del Service Desk) estarán envueltos en las tareas como: Tratar el servicio de demandas Controlar los detalles de los incidentes, incluyendo el punto de configuración afectado Investigación de incidentes y diagnostico (incluyendo la resolución si es posible) Detectar posibles problemas y el encargo de ellos a la gestión del problema La resolución y restablecimiento de los incidentes asignados Terminología Algo que ocurre y causa una interrupción o disminución de un servicio y que no es parte de la operación común de un servicio acordado se llama una incidencia. En la mayoría de los casos las incidencias están interrumpiendo el servicio, algunas veces sólo está reduciendo el servicio, igualmente se denominan incidencias. En muchos casos la incidencia es reactiva (ya ha interrumpido o reducido el nivel de servicio), en otros podemos ser pro-activos advirtiendo sobre esa incidencia y con suerte lo resolveremos antes de que el cliente lo averigüe. Un workaround es un método de evitar una Incidencia o un Problema desde una solución temporal. Es habitualmente la primera solución que restaura el servicio. No es una solución permanente pero algo que se implementa para hacer que el servicio continúe sin sobresaltos. Redirigir trabajos de impresión a otra impresora en el mismo edificio es un workaround. El usuario puede obtener los solicitado pero tal vez a costa de buscarlo en otro piso. Una petición de servicio podría ser una solicitud de información o una solicitud de cambio relacionado con uno de los servicios que entrega la organización. Es, de hecho, cada llamada que no es una incidencia. Una petición de servicio puede ser la solicitud de un cambio que mientras esté cubierto por un servicio prestado de forma estándar es tramitado por Gestión de Incidentes, pero si el servicio no es estándar y altera el estado de la infraestructura de IT (CI) entonces se inicia los que se denomina una Petición de Cambio (RFC). Inputs del servicio: Incidencias del Service Desk Es obvio, pero el proceso no existe si no se registran las incidencias. Información de Configuración La CMDB como veremos más adelante es uno de los mayores proveedores de información para este proceso. Las relaciones entre los Cl s (Ítems de Configuración de la infraestructura de IT), entre los Cl s y expedientes de incidencias anteriores, errores conocidos, cambios y acuerdos de niveles de Servicio, la historia y más información detallada sobre los Cl s es crucial para la solución de incidencias. Respuesta de emparejar incidencias con problemas y Errores Conocidos (KE Known Error) Si la incidencia puede ser comparada con un problema y/o un error conocido es información valiosa que nos puede ayudar a resolverla más rápidamente. Detalles de resolución Los detalles sobre resoluciones anteriores de incidencias- y no sólo los parecidos o los mismos- es de nuevo información valiosa para una rápida restauración del servicio. 89 Respuestas sobre Pedidos de Cambios (RFC) para resolución de incidencias Feedback de la organización de Gestión de Cambios sobre los resultados del cambio para que podamos revisarlos. Outputs del servicio: Pedido de cambios (RFC) para resolución de incidencias Necesitamos RFC s para la restauración de servicio que se debe alcanzar mediante cambios. Este proceso los generará. Incidencias resueltas y cerradas La solución de incidencias y expedientes cerrados con toda la información necesaria sobre cómo se resolvió es información valiosa para la Gestión de Problemas Comunicación a los Clientes El establecimiento de una fluída comunicación durante el ciclo de una incidencia entre el Service Desk y los clientes/usuarios finales es vital. Información de Gestión (Informes) Información de Gestión sobre los resultados y rendimiento del proceso. El Ciclo de vida de la Incidencia Aceptar el evento de servicio, Registrar y consultar la CMDB Admisión y registro del incidente (por el usuario, un sistema o el Help Desk). Se debe evitar registrar el mismo incidente dos veces, por tal motivo se verifica si no existen similares ya reportados. De existir, se relacionan. El registro de datos de acuerdo a la interrupción o reducción del servicio es muy importante para: Localizar la incidencia a lo largo de la totalidad de su ciclo de vida Añadir información útil que puedan ayudar, informar y asistir organizaciones de soporte para que puedan encontrar una solución o un workaround (antes) Recoger información histórica para su uso futuro Coleccionar información (p.ej. para informes) sobre un número de incidencias, eficiencia, disponibilidad y análisis de tendencias y otros procesos de gestión Consultar la CMDB es necesario para obtener información sobre el servicio que se interrumpe, los datos de los Acuerdos de Nivel de Servicio, los CI s relacionados a este servicio, incidencias pasadas, errores conocidos, etc. Clasificación El Service Desk determina la prioridad de las incidencias a medida que las recibe. Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y la urgencia de la incidencia. El impacto se mide en términos de número de usuarios o procesos afectados. La urgencia es la demora aceptable por el usuario o proceso de negocio. La clasificación ayuda a indicar la ruta de solución. Comparación y escalado 910 Se investiga si hay incidentes similares o trabajos en curso. Se debe contrastar contra la base de datos de incidencias, problemas y errores conocidos. En cuanto al escalado puede ser horizontal o funcional y vertical o jerárquico. Investigación y Diagnóstico De acuerdo a como fue derivado el incidente otros grupos de soporte investigarán el mismo y darán su diagnóstico y posible solución. Resolución y recuperación del servicio Una vez encontrada la solución esta se aplica de forma permanente, o de no ser esto posible, se implementa un workaround. Para algunas resoluciones se deberá emitir una petición de cambio (RFC). Cierre Si se indica una solución permanente o un workaround esto lo implementaremos y restauraremos el servicio. El grupo de solución informará al Personal del Service Desk. El Personal del Service Desk investigará con el cliente si la solución/workaround ofrecidos han restaurado el servicio como se requiere. Si es el caso, entonces el Personal puede cerrar la incidencia. Seguimiento y Monitoreo Luego del cierre se deberá seguir el control del incidente para ver si la respuesta es la adecuada y como evoluciona Clasificación: Prioridad y Categoría El Service Desk determina la prioridad de las incidencias a medida que las recibe. Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y urgencia de la incidencia, considerada frente al criterio descrito en el Acuerdo de Nivel de Servicio y lo antedicho más arriba. El criterio típico debería incluir: Coste potencial de la no-resolución Amenaza de lesión a clientes o empleados Implicaciones legales Trastorno a clientes y empleados Al priorizar las llamadas en este punto, el soporte de segunda línea puede determinar fácilmente qué llamadas necesitan atención más urgente y en qué orden. La Prioridad no trata simplemente de poner las incidencias en orden para su resolución; también trata sobre los recursos (tiempo, personal, destreza, investigación y soporte de terceros) que se asignarán a la resolución. En términos prácticos, a veces una incidencia de baja prioridad puede que se permita no alcanzar su tiempo objetivo de resolución, para que una incidencia de más alta prioridad pueda tratarse dentro de su objetivo. La categorización se hace para agrupar incidencias en una categoría específica. La ventaja más grande es que esto podría ayudar a indicar la ruta de solución que se podría tomar, el grupo de solución que se debería elegir (para referir a la incidencia también) y la posible solución. Después de la categorización, la incidencia se debe contrastar con la base de datos de incidencias, problemas y errores conocidos para investigar si se informaron 1011 incidencias con los mismos síntomas antes y averiguar si existen problemas y/o errores conocidos. Si existen, lo más probable es que haya un workaround que podamos utilizar para restaurar el servicio. Si la incidencia no se puede relacionar entonces es una incidencia única. La solución lo más probable es que no pueda encontrarse en el Service Desk y por lo tanto, tenemos que referirlo al siguiente nivel de soporte. A menudo, nos referimos a los departamentos y grupos de soporte (especialistas) además Service Desk como grupos de soporte de segunda o tercera línea, teniendo más habilidades, conocimientos, especialistas, tiempo u otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea. El procedimiento tradicional seria: Paso 1. Intento de resolución de la incidencia por parte del Service Desk: Llevar a cabo la evaluación inicial y buscar una solución o workaround. Si se encuentra una solución, cerrar la incidencia. Si no, referirlo al siguiente nivel. Paso 2. Asignar la Llamada de Servicio al soporte de 2 línea o administración de soporte. Si el soporte de 2 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel. Paso 3. Asignar la Llamada de Servicio al soporte de 3 línea (desarrolladores y especialistas). Si el soporte de 3 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel. Paso 4. Asignar la Llamada de Servicio al especialista o proveedor externo necesario. Si el especialista o proveedor puede encontrar una solución, referir de vuelta al Service Desk que cerrará la incidencia. Si no está claro qué grupo de soporte debería investigar o resolver una incidencia relacionada con un usuario, el Service Desk, como dueño de todas las incidencias, debería coordinar el proceso de Gestión de Incidencias. Si hay diferencias de opinión o surgen otros asuntos, entonces el Service Desk debería escalar la incidencia al equipo de Gestión de Problemas. Escalada y Referencia Si necesitamos más soporte de la dirección, más dinero y más poder (decisiones) para resolver una incidencia, es necesaria la escalada vertical o jerárquica. Si necesitamos involucrar más gente para resolver el incidente, más departamentos, más conocimiento se denomina escalada horizontal o funcional. Debería haber un procedimiento para ambas escaladas. Y es muy importante que el personal del Service Desk monitorice el progreso de la misma. La Escalada o Referencia nunca convierte una incidencia en un problema, aunque pueda resultar en que la propiedad de una incidencia pase al Director de Problemas por razones administrativas. Informar es muy importante. La Mejora de Calidad está basada fundamentalmente en Información. Sin registro de alta calidad e informes flexibles no tenemos la información que necesitamos. Informes sugeridos Revisiones diarias de Incidencias individuales y status de Problemas con referencia a niveles de Servicio Revisiones de gestión semanales o Revisiones de gestión mensuales Informes de servicio pro-activos 1112 Gestión de Problemas La Gestión de Problemas tiene como objetivo manejar todo tipo de servicios de IT fallidos. Su objetivo principal es identificar las causas raíz de aquellas fallas y recomendar cambios en los Items de Configuración (CI s) a Gestión de Cambios. La Gestión de Problemas brinda soporte a Gestión de Incidencias suministrando soluciones temporales y reparaciones rápidas (quick fixed), pero no resuelve incidentes, dado que su función es tomarse el tiempo necesario para investigar la causa raiz de los problemas. El primer objetivo de Gestión de Problemas es minimizar el impacto adverso de Incidencias y Problemas en el negocio causados por errores inherentes a la infraestructura de IT. El segundo es prevenir la recurrencia de Incidencias relacionadas con estos errores. A fin de alcanzar este objetivo, Gestión de Problemas busca llegar a la causa raíz de las Incidencias y entonces iniciar acciones para mejorar o corregir la situación. Parte de la responsabilidad de Gestión de Problemas es asegurar que la información previa está documentada de tal manera que está disponible para el Personal de primera línea y otros de segunda línea. El proceso de Gestión de Problemas tiene aspectos tanto proactivos como reactivos. El aspecto reactivo se ocupa con resolver Problemas en respuesta a una o más Incidencias. Gestión de Problemas Proactiva se ocupa de identificar y resolver Problemas y Errores Conocidos antes de que las Incidencias ocurran en primer lugar. Las actividades de Gestión de Problemas son: Control de Problemas: Esta función realizará análisis de tendencias; registrará problemas y realizará análisis de causas raíz para aquellos problemas a fin de encontrar una solución permanente y que se conviertan en un error conocido. Control de Errores Conocidos: Controla los errores conocidos, genera RFCs a Gestión de Cambios para eliminar los errores conocidos de la infraestructura. Mantiene las bases de datos de conocimiento y errores conocidos/workaround. Publica los errores conocidos para que el Proceso de Incidencias pueda resolver antes incidencias e investigará si problemas y/o errores conocidos también están presentes o no en otras partes de la infraestructura. Prevención Pro-activa: Previene la introducción de nuevas incidencias y problemas Identificar Tendencias: Esta función monitorea activamente las incidencias y con el uso de métodos estadísticos intenta identificar tendencias para que se puedan reconocer problemas. Las tendencias por sí solas habitualmente no son suficiente para identificar un problema, el conocimiento humano es necesario para determinar si la tendencia lleva a un problema. Información de Gestión: Crea informes sobre la efectividad y el rendimiento de la Gestión de Problemas y proporciona esta información a Dirección y otros procesos. Revisión de Post Implementación (PIR): Gestión de Problemas archiva las solicitudes de Cambios. Sólo después de implementar un cambio, puede uno tomar la determinación de si el cambio de hecho hizo lo que esperaba La Revisión de Post Implemento (PIR) comprueba si se da el caso. El encargado del problema tiene las siguientes responsabilidades: 1213 Desarrollar y mantener el proceso de control de problemas Revisar la eficiencia y la efectividad del proceso de control de problemas Informes y métricas de la Gestión de Producción Asignación de los recursos dependiendo del esfuerzo del soporte Monitorear la efectividad del control de errores y conseguir las recomendaciones para mejorarla Identificar los problemas (analizando los datos del incidente, por ejemplo ) Investigar los problemas, según el impacto, a través de la resolución o la identificación del error Solicitar los RFC s para despejar los errores Monitorear los procesos en la resolución de errores conocidos Avisar al personal de gestión de incidentes de la mejor solución alternativa disponible para los incidentes relacionados con los problemas no resueltos o errores conocidos Asistir con el manejo de los mayores incidentes e identificando la causa Identificar las tendencias y la principal fuente de problemas (revisando los incidentes y analizando los problemas) Solicitar los RFC s para prevenir que surja de nuevo los problemas Prevenir la réplica de los problemas a través de sistemas múltiples Inputs del Servicio lnputs a Gestión de problemas son cualquier cosa que podría ayudar a determinar problemas. Los más importantes son: Detalles de Incidencias Toda la información disponible sobre Incidencias se debe pasar a Gestión de Problemas para investigación y análisis de tendencias. Detalles de configuración Como en la Gestión de Incidencias, la CMDB es una de los mayores proveedores de información de este proceso. Las relaciones entre los CI s mismos pero también entre los Cl s y expedientes de CI s anteriores, errores conocidos, cambios y SLA, historia e información más detallada sobre los CI s es información crucial para la resolución de incidencias Workarounds definidos Todos los workarounds definidos son necesarios para determinar si hay incidencias que por su mero número podrían ser definidos como problema. La correlación entre incidencias y workarounds sólo es posible si se conocen los workarounds. Outputs del servicio El proceso de Gestión de Problemas conoce varios outputs, todos dirigidos a eliminar o reducir los efectos de incidencias. Los más importantes son: Errores Conocidos Para que los usuarios (vía el Service Desk) sepan que algo se está investigando Solicitudes de Cambios Para que los usuarios (vía el Service Desk) sepan que una solución se implementará pronto 1314 Expedientes de Problemas actualizados incluidos workarounds y soluciones Para que el Personal de soporte pueda resolver incidencias en forma previa Respuesta a gestión de Incidencias a partir de emparejamiento Para ayudar el proceso de gestión de incidencias a reducir su tiempo de resolución de incidencias Información de Gestión Para informar a dirección si los outputs anteriores cumplen su objetivo. Control de Problemas - Pasos 1 - Identificación y Registro Las formas de identificar un problema son: Si hubo una incidencia con considerable impacto que hemos solucionado lo más probable es que el Director de Problemas registrará un problema enseguida porque una investigación para averiguar la causa raíz de un problema es muy importante Durante el análisis de tendencias podríamos encontrar un número de incidencias con síntomas similares Si descubrimos una fuente de potenciales problemas Si una incidencia se cierra con el código workaround Si un problema se envía a otro dominio 2 - Clasificación. El paso de clasificación recoge datos acerca de Qué CI s están involucrados; Cuáles son las incidencias relacionadas; Cuáles son los síntomas; Cuáles son las causas; Cuáles son las resoluciones/ workaround; Cuáles son los cambios relacionados a este CI; Qué niveles de servicio están relacionados Cuál es el peligro Qué clientes están implicados Cuánto tiempo necesitamos (esperamos) para encontrar una solución (tanto de duración como de esfuerzo) Con cuánta urgencia necesitamos resolver el problema Cómo de alto es el posible beneficio positivo si solucionamos el problema (impacto) Basado en esta información se asigna Impacto y Urgencia (=prioridad). 3 - Asignar Recursos Después de la clasificación, podemos priorizar los problemas. Basado en el número de recursos que tenemos, ahora podemos asignar o reasignar problemas a los recursos disponibles. Al hacerlo de esta manera nos aseguramos de los problemas más importantes con el impacto de negocio más alto. 4 - Investigación y diagnóstico El objetivo de la investigación y diagnóstico es detectar la causa subyacente de una o más incidencias. Las actividades de investigación deberían incluir los Workarounds disponibles para las Incidencias relacionadas con el Problema, como 1415 registradas en la base de datos de expedientes de Incidencias, también como expedientes exactos de Cambios recientes, porque pueden proporcionar orientación a la causa. Información histórica de Cl s (de la CMDB) podría ser útil también como hechos, descripciones y soluciones de datos de incidencias 5 - Establecer un Error Conocido Después de la fase anterior, se determinará el error conocido. Esta fase registra que un error es conocido, se identifica la causa raíz del problema, se identifican los CI intervinientes y pasa el error al proceso de Control de Errores. Control de Errores - Pasos El control de errores conocidos es responsable del registro, monitorización y manejo de todos los errores conocidos desde el principio (la identificación) hasta el cierre después de haber implementado con éxito el cambio que ha eliminado la causa de raíz. 1 - Identificación de error y registro Un error se identifica cuando se detecta un CI roto. Un estatus de Error Conocido se asigna cuando se encuentra la causa raíz de un Problema 2 - Evaluación del Error Este paso realiza una evaluación inicial de los medios de resolver el error, en colaboración con personal especialista. El proceso de resolución para cada Error Conocido debe ser grabado en el sistema de Gestión de Problemas. Es vital que los datos de los CI s, síntomas y acciones de resolución o workaround relacionados con todos los Errores Conocidos se registren en la base de datos de Errores Conocidos porque entonces está disponible para emparejamiento de Incidencias, proporcionando una guía para futuras investigaciones y para proporcionar información de gestión. 3 - Registro del Error / Resolución (envío de RFC) El paso registra una resolución de un error y completa una RFC de acuerdo con los procedimientos de Gestión de Cambio. La prioridad de la RFC se determina por la urgencia e impacto del error en el negocio. El identificador de la RFC debería incluirse en el registro del Error Conocido y viceversa a fin de mantener un rastro de auditoria completo, o se debe ligar los dos registros. Las etapas finales de la resolución de error- análisis de impacto, evaluación detallada de la acción de resolución a llevar a cabo, modificación del artículo en error, y la prueba del Cambio- están bajo el control de Gestión de Cambio. 4 - Cierre de Error Tras implementar con éxito los Cambios (determinado por la Revisión Post Implemento) para resolver errores, el Error Conocido relevante se cierra, junto a los expedientes de Incidencias o Problemas relacionados. Gestión de Problemas Proactiva - Pasos La Gestión de Problemas Proactiva cubre las actividades dirigidas a identificar y resolver Problemas antes de que ocurran Incidencias. Estas actividades son: Análisis de tendencias Marcar objetivos de acción de soporte Proporcionar información a la organización. 1516 Las actividades de Gestión de Problema pro-activa tratan de identificar y resolver Problemas y Errores Conocidos antes de que ocurran Incidencias, dicho de otro modo minimizando-el impacto adverso en el servicio y los costes relacionados con el negocio. La prevención de problemas llega desde la prevención de Problemas individuales hasta decisiones estratégicas. Las últimas puede que requieran mayor gasto de implementar tal como una inversión en una mejor red de conexión. Las actividades principales dentro de los procesos de Gestión de Problemas proactiva son análisis de tendencias y el marcar objetivos de acción preventiva. El análisis de tendencias puede llevar a la identificación de fallos en la infraestructura de IT, los cuales pueden ser entonces analizados y corregidos tal y como se describe en las secciones de Control de Errores y Problemas. El análisis de tendencias también puede llevar a la identificación de áreas de Problemas generales que necesitan más atención de soporte. Debería ser posible hacer comparaciones significativas al expresar esto en términos de coste financiero a la organización. Los informes de análisis de Problemas e Incidencias proporcionan información de medidas pro-activas para mejorar la calidad de servicio. El objetivo es identificar los componentes frágiles de la infraestructura de IT e investigar las razones para la fragilidad- en este contexto la fragilidad es proporcional al impacto al negocio si falla el CI. Incidencias versus Problemas Incidencias y Problemas (y Cambios) son entidades separadas. Las incidencias, problemas e incluso cambios estarán vivas simultáneamente. Si en algún momento durante la fase de diagnóstico se encuentra un workaround la incidencia se resuelve, pero no significa que el problema dejó de existir (sólo cambiaría la urgencia dado que sería más baja) Comienzo: Sólo una incidencia. Cuando ocurre una incidencia, el proceso de gestión de incidencia intentará resolver la incidencia cuanto antes. La incidencia sólo se puede cerrar una vez resuelta la incidencia. Durante la fase de investigación de la incidencia, no se encuentra ninguna solución. El proceso de gestión de incidencias entonces busca la ayuda de gestión de problemas porque la causa raíz de las incidencias se tiene que determinar en primer lugar. Investigado y Escalada: Incidencia y Problema existen simultáneamente. La gestión de problemas define un problema con alta urgencia e inmediatamente asigna recursos. Esos recursos diagnostican el problema y encuentran la causa raíz de la incidencia subyacente. Diagnóstico: Incidencia, Problema y Error Conocido existen simultáneamente. Definen un error conocido y tras averiguar cómo resolverlo emiten una RFC a gestión de cambio para resolver la situación. Cambio en trámite: Incidencia, Problema, Error Conocido y Cambio existen simultáneamente El cambio se implementa con éxito. La Revisión Post implementación muestra que el cambio de hecho ha eliminado el error conocido con éxito. La investigación muestra también que la incidencia se ha resuelto y el problema, por lo tanto, abierto por esta razón ahora se puede cerrar también. Final: Incidencia resuelta, cambio, problema y error conocido cerrados 1617 Si en algún momento durante la fase de diagnóstico el equipo de problemas encuentra un workaround, la incidencia se resolverá antes. Esto no significa que el problema ya no exista. El único cambio en el expediente del problema será que la urgencia caerá de urgente a no urgente. El proceso de problemas decidirá si hay recursos suficientes libres en ese momento en el tiempo para perseguir el diagnóstico del problema o si esos recursos fuesen mejor utilizados en otro lugar. Procesando Errores Conocidos desde el Entorno de Desarrollo La segunda fuente de Errores Conocidos surge de la actividad del desarrollo. Por ejemplo, la implementación de una nueva aplicación o Difusión empaquetada es probable que incluya errores conocidos, pero sin resolver, de la fase de desarrollo. Los datos relacionados con Errores Conocidos del desarrollo necesitan estar a disposición del Service Desk del entorno vivo cuando una aplicación o un paquete de Difusión se implementan. Informes de Gestión La información de gestión debería proporcionar una vista interna del esfuerzo y recursos gastados por la organización en investigar, diagnosticar y resolver Problemas y Errores Conocidos. Además de esto, es importante proporcionar una percepción del progreso hecho y los resultados obtenidos como resultado. Las medidas se tiene que seleccionar con cuidado. Sólo mediante medidas cuidadosas y significativas puede la dirección formar una opinión de la calidad de un proceso. Algunas medidas sugeridas son: Los números de RFCs surgidos y el impacto de esas RFCs en la disponibilidad y fiabilidad de los servicios cubiertos La cantidad de tiempo trabajado en investigaciones y diagnósticos por unidad organizacional o de proveedor, dividido por tipos de problema El número e impacto de incidencias que ocurren antes de que se cierre el problema de raíz o se confirme un error conocido La proporción de esfuerzo de soporte inmediato (reactivo) frente a esfuerzo de soporte programado en gestión de problemas Los planes de resolución de problemas abiertos con relación a los recursos: Personas Otros recursos utilizados Costos (contra presupuesto) 1718 Gestión de Cambios IT se está volviendo cada vez más crítico en operaciones de negocio. La velocidad de cambio de condiciones de negocio aumenta. La velocidad de cambio de tecnologías aumenta. Los Usuarios exigen mayores niveles de servicio para alcanzar los objetivos de los roles que sirven en el negocio. Todos estos factores exigen un entorno de IT en el que el cambio se gestiona y controla de manera cercana. La experiencia sugiere que un alto porcentaje de problemas relacionados con la calidad de servicio de IT se puede rastrear hasta algún cambio que se hizo en el sistema. El primer objetivo del proceso de Gestión de Cambio es asegurar que se utilizan procedimientos y métodos estandarizados para el manejo eficiente y puntual de todos los cambios, a fin de minimizar el impacto de los cambios sobre la calidad de servicio y la continuidad del negocio. Este enfoque es esencial para mantener un equilibrio apropiado entre la necesidad de cambio frente al impacto de cambio. Es particularmente importante que los procesos de Gestión de Cambio tengan alta visibilidad y canales de comunicación abiertos a fin de promover transiciones suaves cuando un cambio tiene lugar. Dentro de la declaración de misión, la frase cambios aprobados es muy fuerte y rígida. Esto casi insinúa inflexibilidad, aunque una política de Gestión de cambio bien documentada y rigurosa responderá por los pequeños cambios diarios y los cambios necesarios para restaurar inmediatamente un servicio crítico o uno que impacta a un gran número de clientes. Por ejemplo, para que un usuario cambie su clave de acceso, una Solicitud de Cambio completa y una reunión de seguimiento de la Junta de Asesoramiento de Cambio para aprobación sería poco razonable. Además, un cambio necesitado inmediatamente para restaurar un servicio crítico debería seguir un camino de proceso distinto de los cambios normales. Para algunos, la idea de implementar una serie amplia de procesos de Gestión de Cambio a lo largo de funciones, con documentación formal, reuniones, y aprobaciones parece añadir burocracia y que el Proceso de Gestión de Cambio atará las manos de aquellos que necesitan hacer los cambios para mantener en pie el entorno de IT. En realidad, una serie de procesos de Gestión de Cambio (y Gestión de Configuración) adecuada debería reducir la necesidad de cambios ad hoc que se puedan encontrar en entornos con pocas o ninguna política de gestión de Cambio o Configuración. Para aquellos cambios que sí hacen falta, un proceso de Gestión de Cambio o Configuración bien diseñado debería procesar y aprobar cambios de manera diligente. Estos cambios aprobados llevan el respaldo de la dirección de IT y se han filtrado tanto el nivel de riesgo, costos e impacto en la organización. Gestionar cambios se ha convertido en una ocupación de tiempo completo. Si los cambios se pueden manejar para optimizar la exposición al riesgo, la severidad del impacto y trastorno, y claro está, tener éxito al primer intento, el fin para el negocio es llevar a cabo cuanto antes este proceso. Los Cambios surgen como resultado de Problemas, pero muchos Cambios se producen por la búsqueda anticipada de beneficios empresariales tales como reducción de costos o mejora de servicios. El objetivo del proceso de Gestión de Cambios es asegurar que los métodos y procedimientos estandarizados sean usados para un manejo eficiente y rápido de todos los Cambios, para minimizar el impacto de los Incidentes relacionados con los Cambios en la calidad del servicio, y como consecuencia la mejora de las operaciones cotidianas de la organización. 1819 Es particularmente importante que el proceso de la Gestión de Cambios tenga una alta visibilidad y canales de comunicación abiertos para fomentar transiciones suaves cuando los Cambios tengan lugar. La Gestión de Cambios es responsable de la gestión de los procesos de Cambio, implicando: Hardware Equipamiento de las comunicaciones y software Software de sistemas Software de aplicaciones vivas Toda documentación y procedimientos asociados a la ejecución, soporte y mantenimiento de sistemas vivos. Esto significa que los cambios de cualquier componente que estén bajo el control de un Proyecto de desarrollo de aplicaciones (por ejemplo, software de aplicaciones, documentación y procedimientos) no son objeto de la Gestión de Cambios, sino que estaría sometido a los procedimientos de proyecto de Gestión de Cambios de administración del Proyecto. El equipo de Gestión de Cambios se supone, sin embargo, que se comunica estrechamente con el responsable del proyecto de desarrollo de la Aplicación (Project Manager) para asegurar una implementación fluida y lógica dentro de los entornos variables de gestión. Mientras la Gestión de Cambios es responsable de dirigir el proceso, la autoridad de decisión es el Consejo Asesor de Cambios (CAB), el cual es llevado a cabo por la mayor parte de la gente de otros departamentos dentro de la organización. Gestión de Cambios es responsable de dirigir el Proceso de Cambios. Este proceso no está al cargo de implementar cambios, sólo controlará que se aprueben cambios y que se implementen de forma eficiente, de forma efectiva en lo que se refiere a coste y con un mínimo riesgo para los servicios nuevos y existentes. A fin de hacer esto de modo correcto, necesitamos un proceso. Pero también procedimientos y guías muy detallados de cómo hacer distintas cosas en el proceso. Para evaluar el riesgo de cada cambio es muy importante que tengamos una idea de la configuración que controlamos. Por eso, necesitamos Gestión de Configuración, que es la responsable de garantizar que la información relativa a las posibles implicaciones de un Cambio propuesto esté disponible, y que los posibles impactos sean detectados y presentados apropiadamente. Habrá ocasiones en las que una infraestructura de Cambios propuesta tendrá, potencialmente, un impacto más amplio sobre otras partes de la organización (por ejemplo proyectos de desarrollo de aplicaciones u operaciones de empresa), o viceversa. Para mitigar posibles impactos negativos desde cualquier dirección, es imperativo que la infraestructura y otros sistemas de Gestión de Cambios sean enlazados apropiadamente. Terminología Cambio: Añadir, modificar o eliminar hardware, software, aplicación, entorno, sistema, documentación asociada, etc. RFC (Solicitud de Cambio): Formulario, o pantalla, usado para grabar los detalles de una solicitud de cambio a cualquier CI dentro de una infraestructura o a procedimientos asociados con la infraestructura. Programa Adelantado de Cambios (FSC): Programa que contiene los detalles de todos los Cambios aprobados para implementar y sus fechas propuestas de implementación. 1920 Comité de Aprobación de Cambios (CAB): cuerpo de consulta que se reune a menudo en forma formal o informal para la aprobación de los cambios. Cuando surgen problemas mayores es necesario una junta más pequeña para tomar decisiones de urgencia y se denomina CAB/EC (comité de urgencia) Inputs al servicio RFCs : solicitud de cambios a ítems de la configuración de la infraestructura (cambios a CI) o a procedimientos o artículos relacionados con IT. CMDB: información sobre que ítems son los que cambiarán o se verán afectados por el cambio FSC: programa de cambios aprobados para implementar a largo plazo (fechas propuestas y planificadas de cambios) Outputs del servicio Las salidas del proceso serán: FSC RFCs Actas y acciones de CAB Informes de Gestión de Cambios. Los deberes del Responsable de Cambios, algunos de los cuales pueden ser delegados, se listan a continuación: Recibir, registrar y asignar una prioridad, en colaboración con el iniciador, de todas las RFCs. Rechazar cualquier RFC que no sean completamente prácticas. Presentar todas las RFCs para una reunión CAB, publicar una agenda, y hacer circular por adelantado de RFCs de reuniones a miembros CAB para permitir consideraciones previas. Decidir qué personas irán a qué reuniones, las cuales tienen RFCs específicas dependiendo de la naturaleza la RFC, que va a ser cambiada, y del área de conocimiento de la gente. Convocar CAB urgentes o reuniones CAB/EC para todas las RFCs urgentes. Presidir todas las reuniones CAB y CAB/EC. Después de la consideración del consejo dado por CAB o CAB/EC, autorizar cambios aceptables. Publicar FSCs, via Service Desk Comunicar con todos los grupos para coordinar la construcción de Cambios, prueba e implementación, de acuerdo con los programas. Actualizar el registro de Cambios con todos los avances que ocurran, incluyendo cualquier acción para corregir problemas y/o aprovechar para mejorar la calidad del servicio. Revisar todos los cambios implementados para asegurar que hayan conseguido los objetivos completamente. Remitir de vuelta cualquiera que haya sido vuelto atrás o haya fallado. Revisar todas las RFCs destacadas en espera de acción. Analizar los registros de Cambios para determinar cualquier tendencia o problema aparente que ocurra. Buscar rectificaciones con los grupos relevantes. Cerrar RFCs. Producir informes regulares y exactos de gestión. Responsabilidades del Consejo Asesor de Cambios (CAB) 20 Mostrar más
La Administración n de Servicios ITIL Noviembre, 2006 1 1 ITIL y Administración n de Servicios IT DEFINICIONES ITIL: Infraestructure Technology Infraestructure Library Brinda un conjunto detallado de mejores Más detalles Prácticas ITIL para un mejor flujo de trabajo en el helpdesk
Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Se diferencia tres partes de gestión para mejorar la resolución de las incidencias de soporte técnico según el marco ITIL: 1. Gestión de Incidencias Más detalles Gerencia informática. Tema: Operación del servicio. Autor: Osvaldo Puello Flórez
Gerencia informática Tema: Operación del servicio Autor: Osvaldo Puello Flórez Propósito de la Operación El propósito principal de la operación del servicio es coordinar y ejecutar las actividades y los Más detalles Recursos HELP DESK Biblioteca 2012
Seguridad del documento La clasificación de seguridad de la información de este documento, se ha establecido como bajo. Se ha creado y organizado con la expectativa de que esté a disposición de las unidades Más detalles Figura 3.1 Implementación de ITIL
75.46 - Administración y Control de Proyectos II Sergio Martinez 1er cuatrimestre 2006 Introducción Qué es un Servicio? Cliente Lavandería Transporte Lavadero Industrial Precio por el Servicio Mismo día:\300 Más detalles Administración de servicios: cómo brindar un mejor servicio con una CMDB
Examen de Fundamentos de ITIL Ejemplo B, versión 5.1 Selección Múltiple Instrucciones 1. Debe intentar contestar todas las 40 preguntas. 2. Marque sus respuestas en la hoja de respuestas entregada 3. Usted Más detalles PROCEDIMIENTO GESTION DE CAMBIOS
PROCEDIMIENTO: GESTION DE CAMBIOS Número de página 1 de 24 PROCEDIMIENTO GESTION DE CAMBIOS PROCEDIMIENTO: GESTION DE CAMBIOS Número de página 2 de 24 1. INFORMACIÓN GENERAL. 1.1 OBJETIVO Preservar la Más detalles MODULO: MERCADEO. Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) MODELO DE MUESTRA SIN VALOR COMERCIAL
MODULO: MERCADEO Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) 1 Servicio de Soporte. El presente apartado constituye las condiciones de soporte y mantenimiento por parte de enncloud Más detalles LINEAMIENTOS DE MONITOREO Y CONTROL
Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN ------------------------------------------------------------------------------------------- --3 1. OBJETIVO -------------------------------------------------------------------------------------------- Más detalles GESTION DE SERVICIOS TIC (Tecnología de la información y las comunicaciones) ITIL (Biblioteca de Infraestructura de Tecnologías de Información)
GESTION DE SERVICIOS TIC (Tecnología de la información y las comunicaciones) ITIL (Biblioteca de Infraestructura de Tecnologías de Información) Autores: Lic. Lobos Anfuso, Daniela de los Ángeles Lic. Baquinzay. Más detalles ITIL. 75.46 - Administración y Control de Proyectos II
REVISTA DE DIVULGACIÓN CIENTÍFICA ISSN 1852-3005 DE CIENCIA Y TECNOLOGÍA DE LA UNCa. Volumen 1 Número 1 Diciembre 2008 GESTION DE SERVICIOS TIC (Tecnología de la información y las comunicaciones) ITIL Más detalles Capítulo IV. Manejo de Problemas
Manejo de Problemas Manejo de problemas Tabla de contenido 1.- En qué consiste el manejo de problemas?...57 1.1.- Ventajas...58 1.2.- Barreras...59 2.- Actividades...59 2.1.- Control de problemas...60 Más detalles BMC ProactiveNet Performance Management
SERVICE ASSURANCE INFORMACIÓN DE PRODUCTO DATASHEET BMC ProactiveNet Performance Management Beneficios clave» Genera menos eventos y más inteligentes a través del motor de análisis de autoaprendizaje y Más detalles MATERIA : GESTION DE SERVICIOS DE TI FECHA: Marzo 18 de 2013
Tabla de contenido Métricas de la Gestión de los : Cómo Empezar... 2 Por qué realizar informes de gestión desde los datos de del Centro de Servicio al Usuario?... 2 Clasificación de los Datos de Rendimiento... Más detalles ITIL, el mejor aliado para lograr calidad y eficiencia operativa en beneficio del negocio
ITIL, el mejor aliado para lograr calidad y eficiencia operativa en beneficio del negocio Objetivo General Presentar el caso de implementación de la metodología de ITIL (Information Technology Infrastructure Más detalles Presentación ITIL. Jornadas TIC - Mayo 2008
75.46 Administración y Control de Proyectos II Sergio Martínez Estudios Licenciatura en Informática (USAL) Administración de Proyectos Informáticos (UBA) PMP (PMI) CSM (Scrum Alliance) Experiencia Administración Más detalles TEMA 5: La explotación de un servicio TI
CIMSI Configuración, Implementación y Mantenimiento de Sistemas Informáticos TEMA 5: La explotación de un servicio TI Daniel Cascado Caballero Rosa Yáñez Gómez Mª José Morón Fernández E.T.S. de Ingeniería Más detalles Gestión del Servicio de Tecnología de la información
Gestión del Servicio de Tecnología de la información Comentario de la norma ISO 20000 bajo el enfoque de ITIL Autor: Francisco Tejera (ISO 20000 Practitioner) Agenda 1-2-3 INTRODUCCIÓN 4 5 REQUISITOS GENERALES Más detalles Planificación y Explotación de Sistemas Informáticos Curso 06/07. TEMA 2 ITIL para la gestión de servicios informáticos
Planificación y Explotación de Sistemas Informáticos Curso 06/07 TEMA 2 ITIL para la gestión de servicios informáticos 1 Índice Introducción Modelo de servicios Soporte de servicios Entrega de servicios Más detalles Capítulo III. Manejo de Incidentes
Manejo de Incidentes Manejo de Incidentes Tabla de contenido 1.- En qué consiste el manejo de incidentes?...45 1.1.- Ventajas...47 1.2.- Barreras...47 2.- Requerimientos...48 3.- Clasificación de los incidentes...48 Más detalles Rumboitil www.rumboitil.com e-mail: info@rumboitil.com
Unidad 6 Operación del Servicio... 2 6.1 Introducción y Objetivos... 2 6.2 Gestión de Incidencias.... 2 6.3 Gestión de Problemas.... 12 6.4 Gestión de Eventos... 15 6.5 Gestión de Peticiones.... 17 6.6 Más detalles Acuerdo de Nivel de Servicio del Centro de Servicios al Usuario. Gestión de Nivel de Servicio de SGS
Acuerdo de Nivel de Servicio del Centro de Servicios al Usuario Gestión de Nivel de Servicio de SGS Vicerrectorado de TIC, Calidad e Innovación SISTEMA DE GESTIÓN DEL SERVICIO (SGS) Título Nombre del Fichero Más detalles Administración de Incidente y Problema
Administración de Incidente y Problema Evolución y Madurez de la mesa ayuda para alcanzar BSM (Business Service Management) WHITE PAPER SOBRE SOLUCIONES Tabla de Contenido Resumen Ejecutivo...1 Transición Más detalles Descripción de ITIL. Grupo B
Descripción de ITIL Grupo B Índice de contenido 1. Introducción 2. Perspectivas de Negocio 3. Planificación de Implantación de Servicio de Gestión 4. Gestión de Infraestructuras ICT 5. Soporte de Servicio Más detalles La Administración n de Servicios ITIL. Noviembre, 2006
La Administración n de Servicios ITIL Noviembre, 2006 1 4.- LA GESTION DE PROBLEMAS 2 4.- LA GESTION DE PROBLEMAS OBJETIVO Minimizar el impacto adverso de los incidentes y los problemas sobre el negocio Más detalles Proyecto 20000-PYME. Introducción al SGSTI (Sistema de Gestión de Servicios TI)
UNIDAD 2 SOPORTE DE SERVICIO GESTIÓN DE INCIDENTES INTRODUCCIÓN Y OBJETIVOS Los objetivos principales de la Gestión de Incidentes son: Detectar cualquiera alteración en los servicios TI. Registrar y clasificar Más detalles WhiteHat Tools. Resumen del Producto
WhiteHat Tools Aplicación para la Administración de Servicios de TI. Resumen del Producto Propiedad de White Hat Consultores S.A. de C.V. Cerrada Sabino Rodríguez 12 Col. El Maestro Delegación Magdalena Más detalles Estándar para la Elaboración del Proceso Administración de Cambios
Seguridad del documento La clasificación de seguridad de la información de este documento, se ha establecido como bajo. Se ha creado y organizado con la expectativa de que esté a disposición de las unidades Más detalles ITIL V3-2011 Preparación para la certificación ITIL Foundation V3
Capítulo 1 Introducción y aspectos generales de ITIL V3 A. Introducción 26 1. El contexto 26 2. Las respuestas a este contexto 27 B. Las buenas prácticas ITIL V3 27 1. Las buenas prácticas 27 a. Introducción Más detalles 10 Cuáles de las siguientes afirmaciones acerca de la Biblioteca Definitiva de Medios (DML) son CORRECTAS? 1. La DML incluye un almacén físico
1 De cuáles procesos la Gestión de Niveles de Servicios podría tomar en cuenta entradas de información para cuando esté negociando Acuerdos de Nivel de Servicio (SLA)? a) De todos los demás procesos de Más detalles LINEAMIENTOS DE ADMINISTRACIÓN DE CAMBIOS
Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN --------------------------------------------------------------------------------------------- 3 1. OBJETIVO ---------------------------------------------------------------------------------------------- Más detalles Definición del Catalogo de Servicios V3. José Ricardo Arias Noviembre de 2010
Definición del Catalogo de Servicios V3 José Ricardo Arias Noviembre de 2010 ITIL vs COBIT Agenda Descripciones Generales ITIL vs COBIT Por dónde iniciar? Cuál es la importancia de la presentación? Las Más detalles DEXON SOFTWARE DEXON SERVICE DESK DIRECTOR
DEXON SOFTWARE DEXON SERVICE DESK DIRECTOR UN COMPLETO PORTAFOLIO QUE ADMINISTRA DE FORMA CENTRALIZADA TODOS LOS PROCESOS DE SOPORTE DE FORMA MAS CERCANA CON LOS CLIENTES CON LA ADOPCIÓN DE PRÁCTICAS PROACTIVAS Más detalles FICHAS DE DESCRIPCIÓN DE FUNCIONES Y COMPETENCIAS LABORALES
Página 1 de 11 I. IDENTIFICACIÓN DENOMINACIÓN DEL CARGO: PROGRAMADOR DE COMPUTADOR SIGLA:PC CLASE: V GRADO: 12-14-16 NIVEL: ADMINISTRATIVO NÚMERO DE CARGOS: ÁREA: 5 JEFE INMEDIATO: 1. OFICINA DE INFORMÀTICA Más detalles INSYS SERVICE DESK. Integración de Servicios
INSYS SERVICE DESK Integración de Servicios INSYS SERVICE DESK es el resultado de la integración de las soluciones: CURA Network Monitoring, INSYS Advanced Dashboard for Enterprise, SIEM (NetIQ Sentinel Más detalles Existiría información que ayude a priorizar cada solicitud en función de su valor de negocio
IT Demand Management Autor: Norberto Figuerola En un mundo perfecto, el departamento de TI responde respondería a todas las solicitudes como una máquina bien aceitada. Cada proyecto propuesto sería aceptado Más detalles Boletín Advisory* En este número
Boletín Advisory* Julio/Agosto 2005 Distribución exclusiva para clientes y relacionados de Espiñeira, Sheldon y Asociados En este número Retos para la organización de TI La problemática: el cliente siempre Más detalles Los os Negocios deben crecer,, No los Problemas.
Los os Negocios deben crecer,, No los Problemas. ManageEngine Como una herramienta HelpDesk acorde con las buenas prácticas ITIL, puede ayudar a las pequeñas y medianas empresas. 1 Agradecimiento a Javier Más detalles Beneficios estratégicos para su organización. Resolución proactiva de problemas y eventualidades. Reducción instantánea de costos de soporte.
Beneficios Gestión organizada y control sobre las solicitudes de soporte. Información completa correspondiente a cada caso y asociación de los involucrados en el mismo (usuarios, especialistas). Seguimiento Más detalles Fecha 8/02/2013. Contenido
Acuerdo de Nivel Mesa Elaborado por: Juan Pablo Pérez Wilson Viana Uribe Fecha 15/01/2013 Código: P-GSI-4xxxxx Versión: 01 Revisado por: Wilson Viana Uribe Fecha 8/02/2013 Aprobado por: Marco Mesa Fecha Más detalles #1 Elaborar una lista de Preguntas Frecuentes (FAQS)
Tu helpdesk debe intentar mejorar constantemente los métodos de interacción con los usuarios y/o clientes. Los usuarios deben sentirse cómodos con el helpdesk y saber que recibirán un soporte efectivo, Más detalles INSTITUTO POLITÉCNICO NACIONAL
INFORME DE SOLUCIONES BMC Remedy IT Service Management Suite Las organizaciones de TI que logran una mayor eficacia, gestionan los costes de forma eficaz, consiguen el cumplimiento normativo y ofrecen Más detalles LINEAMIENTOS DE ADMINISTRACIÓN DE INCIDENTES
Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN --------------------------------------------------------------------------------------------- 3 1. OBJETIVO -------------------------------------------------------------------------------------------- Más detalles LINEAMIENTOS DE ADMINISTRACIÓN DE PROBLEMAS
Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN --------------------------------------------------------------------------------------------- 4 1. OBJETIVO ---------------------------------------------------------------------------------------------- Más detalles POLÍTICA DE GESTIÓN DEL SERVICIO
OBJETIVO DE LA POLÍTICA DEL SISTEMA DE GESTIÓN DEL SERVICIO (SGS) El presente documento tiene por objeto establecer la Política de Gestión del Servicio para FIBRATEL en base a los requisitos dispuestos Más detalles Sistemas de gestión en servicios de TI (UNIT ISO/IEC 20000-1)
ITIL V3 Por dónde empezar? Autor: Norberto Figuerola Introducción La gestión de servicios de TI (ITSM) suministra los servicios que necesita una empresa para cumplir sus objetivos de negocio. ITSM respalda Más detalles Transición del Servicio
Fundamentos de ITIL V3 Transición del Servicio Operaciones y Servicio al Cliente Ing. Paul Ernesto Luque Ybaceta Setiembre de 2011 Agenda Visión General del Diseño del Servicio Metas, Objetivos y Retos Más detalles LINEAMIENTOS DE ADMINISTRACIÓN DE CONFIGURACIÓN
Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN --------------------------------------------------------------------------------------------- 3 1. OBJETIVO ---------------------------------------------------------------------------------------------- Más detalles Information Technology Infrastructure Library (La biblioteca de Infraestructura de Tecnología de Información)
Information Technology Infrastructure Library (La biblioteca de Infraestructura de Tecnología de Información) 1 Information Technology Infrastructure Library Objetivos Del Proyecto: Definir, desarrollar Más detalles Aranda SERVICE DESK. Beneficios estratégicos para su organización. Característica Especiales. Beneficios
Optimice la gestión de soporte y servicio y maneje de manera eficiente estos procedimientos dentro y fuera de su organización, aumentando considerablemente su nivel de productividad. Beneficios Gestión Más detalles Por qué su mesa de servicios actual no es eficaz para su negocio y qué se puede hacer al respecto
INFORME OFICIAL Septiembre de 2012 Por qué su mesa de servicios actual no es eficaz para su negocio y qué se puede hacer al respecto agility agility made possible made possible Tabla de contenido Resumen Más detalles la Información Javier Mayorga Javier.mayorga@co.pwc.com *connectedthinking
ITIL como apoyo a la Seguridad de la Información Javier Mayorga Javier.mayorga@co.pwc.com *connectedthinking AGENDA 1. Antecedentes 2. Conceptos de ITIL 3. Etapas de ITIL 4. Soporte de ITIL a la seguridad Más detalles puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales?
RESUMEN DE LA SOLUCIÓN Service Operations Management puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? agility made possible (SOM) de CA Technologies es una solución Más detalles TABLA DE CONTENIDOS... 2 1. INFORMACIÓN DEL DOCUMENTO... 3 2. OBJETIVO... 3 3. ALCANCE... 3 4. DEFINICIONES Y VOCABULARIO... 3 4.
TABLA DE CONTENIDOS... 2 1. INFORMACIÓN DEL DOCUMENTO... 3 2. OBJETIVO... 3 3. ALCANCE... 3 4. DEFINICIONES Y VOCABULARIO... 3 4. REFERENCIAS Y DOCUMENTOS RELACIONADOS... 4 5. RESPONSABILIDADES... 4 6. Más detalles PROCEDIMIENTO GESTIÓN DE INCIDENTES EN EL SERVICIO SITIOS WEB. PROCEDIMIENTO: Gestión de incidentes en el Servicio Sitios WEB.
Página: 1 de 13 PROCEDIMIENTO: Gestión de en el Servicio Sitios WEB. OBJETIVO: Lograr la restauración de una eventual falla o interrupción presentada en alguno de los sitios WEB, en el menor tiempo posible Más detalles Construyendo una infrastructura ITIL con NetSupport ServiceDesk
TotemGuard Digital Security Construyendo una infrastructura ITIL con NetSupport ServiceDesk Foto Sarah and Mike Totemguard.com 1 902 360 645 Índice 1. Introducción...4 2. Introducción a ITIL...5 3. Introducción Más detalles IT Governance Caso ITIL Santiago Coloma Edo
Caso ITIL Seguros XXXX Índice 1. Es necesaria una CMDB?... 2 2. Creación de un Catálogo de Servicios... 3 Propuesta de Catalogo de Servicios.... 3 Quiénes son nuestros clientes?... 3 Qué servicios ofrecemos?... Más detalles Funciones y Procesos
Funciones y Procesos Trabajo Sistemático Las empresas que sobrevivirán a los cambios continuos y a la inestabilidad de los mercados, serán aquellas que logren llevar a la práctica sus ideas de forma simple, Más detalles Simulacro de Examen de Certificación
NOMBRE: Simulacro de Examen de Certificación 1. Cuántos de los siguientes son procesos ITIL? I. Incident Mgt II. Problem Mgt III. Change Mgt Página 1 de 7 IV. Release Mgt V. Service Desk A. 1 B. 2 C. 3 Más detalles CAPÍTULO 1: EL MARCO DE TRABAJO DE ITIL
CAPÍTULO 1: EL MARCO DE TRABAJO DE ITIL 1.1. Generalidades ITIL (Information Technology Infrastructure Library); Biblioteca de Infraestructura de Tecnologías de la Información, es un conjunto de las mejores Más detalles Escenario Uno. Escenario Dos
Escenario Uno Una compañía global desarrolla sus propias aplicaciones para dar soporte al negocio. La compañía ha implementado la transición del servicio y utiliza validación y pruebas del servicio para Más detalles Fecha 30/07/2014. 1.2. Opciones del servicio... 5. 1.3. Forma de acceder al servicio... 5. 1.4. Cobros por utilización del servicio...
Contenido 1. Descripción del servicio... 3 2. Declaración de la misión... 3 3. Objetivos del servicio... 3 4. Servicios provistos.... 3 5. Servicios NO provistos.... 4 6. Elementos de Gestión del Servicio Más detalles Parte informativo. ISO 9001:2015 Proyecto de Norma Internacional
Parte informativo ISO 9001:2015 Proyecto de Norma Internacional Índice 2 2 Creando la Cimentación para la Gestión de Calidad en una Nueva Era de Negocios 5 Otras revisiones principales en ISO 9001:2015 Más detalles Capítulo VII. Administración de Cambios
Administración de Cambios Administración de cambios Tabla de contenido 1.- En qué consiste la administración de cambios?...97 1.1.- Ventajas...98 1.2.- Barreras...98 2.- Elementos...99 3.- Roles...99 4.- Más detalles PLANTILLA ARTICULO CÓMO
TITULO ID PREGUNTA RESPUESTA Procedimiento Incidentes Masivos KBA00003605 Cómo se establece el procedimiento para el manejo de incidentes masivos y elaboración de reportes de falla por degradación de los Más detalles GRUPAYA PROJECT MANAGEMENT
GRUPAYA PROJECT MANAGEMENT (Febrero 2003) ÍNDICE 1.- GRUPAYA PROJECT MANAGEMENT. 2.- PROJECT MANAGEMENT, ESQUEMA Y DESARROLLO DEL SERVICIO 2.1.- Redacción de proyectos. 2.2.- Análisis de los proyectos Más detalles PROCESO: GESTION INFORMÁTICA PROCEDIMIENTO: GESTION DE CONFIGURACIONES
PROCESO: GESTION INFORMÁTICA PROCEDIMIENTO: GESTION DE CONFIGURACIONES Objetivo del Procedimiento: Identificar y definir los componentes de configuración de los sistemas del SENA, registrando e informando Más detalles IBM Tivoli Asset Management for IT. IBM Tivoli Service Request Manager
for IT & IBM Tivoli Service Request Manager Optimice sus procesos IT, maximice sus activos y mejore el nivel de servicio. Para obtener altos niveles de servicio, reducir costes y alcanzar las metas del Más detalles Proyecto 7 x 24: Cobertura y Mejores Prácticas (ITIL)
Proyecto 7 x 24: Cobertura y Mejores Prácticas (ITIL) Subdirector General Adjunto de Tecnologías y Sistemas de la Información. Ministerio de Fomento Juan Antonio Lago Bagües Gestor de Servicio Ibermática Más detalles Cómo Asegurar la Calidad de Servicios de TI?
Cómo Asegurar la Calidad de Servicios de TI? Martín Ugarteche Crosby Southern Peru Copper Corporation Cuales son los pasos para construir un Sistema de Gestión de Servicios de TI? 1. Voluntad de querer Más detalles Anuncio de software ZP12-0576 de IBM Europe, Middle East, and Africa, con fecha 27 de noviembre de 2012
RESUMEN DE LA SOLUCIÓN Administración de activos de software con CA IT Asset Manager cómo puedo administrar mejor mis activos de software y mitigar el riesgo de las auditorías de cumplimiento? agility Más detalles Gestión ubicua de incidentes y problemas basada en ITIL
Gestión ubicua de incidentes y problemas basada en ITIL LUIS COMPS FORCÉN Director: Eladio Domínguez Murillo Departamento: Informática e Ingeniería de Sistemas Ponente: José Ángel Bañares Bañares Departamento: Más detalles ITIL MEJORES PRÁCTICAS
TUTORIAL V 1 0 0 Centro de Investigación de las Telecomunicaciones CINTEL Avenida Calle 100 No. 19-61 Piso 8 Tel: 6353538 Fax: 6353336 Bogotá D.C. Colombia 2008 CONTENIDO INTRODUCCIÓN... 9 1. ANTECEDENTES... Más detalles invgate Service Desk
invgate Service Desk 02 Información general. 03 Funcionalidades. 06 Beneficios. Índice. 02 Información general. Revolucioná tu departamento IT Gestionar tu departamento de IT es fácil Actualmente los objetivos Más detalles Acuerdo de Nivel de Servicio o Service Level Agreement (SLA) para servicios de Hospedaje Virtual
Acuerdo de Nivel de Servicio o Service Level Agreement (SLA) para servicios de Hospedaje Virtual A continuación detallamos los niveles de servicio garantizados para los servicios de Hospedaje Virtual: Más detalles Service Desk. InvGate IT Management Software
1 Necesita mejorar la calidad del soporte técnico de su empresa, reducir radicalmente los tiempos de respuesta y gestionar con las mejores prácticas los procesos de servicio? Actualmente los objetivos Más detalles 1. Gestionar el ciclo de vida de las solicitudes de servicio que se reciben de los usuarios de los servicios de TIC.
5.9 OPERACIÓN DE SERVICIOS 5.9.1 Operación de la mesa de servicios 5.9.1.1 Objetivos del proceso General: Establecer y operar un punto único de contacto para que los usuarios de los servicios hagan llegar Más detalles Administración de Centros de Computo. ITIL. MSG.ING. DARWIN CERCADO B dcercado@primma.com.ec
Administración de Centros de Computo. ITIL dcercado@primma.com.ec Situación Procesos de negocio complejos y cambiantes, tiempos acelerados y un mercado global imponen requerimientos exigentes. El negocio Más detalles HP Foundation Care Exchange Service
Datos técnicos HP Foundation Care Exchange Service HP Servicios Ventajas del servicio Proporciona acceso a los recursos técnicos de HP para la resolución de problemas Pudiera contribuir a mejorar el rendimiento Más detalles SAP SOLUTION MANAGER 7.1 Service Desk MANUAL DE USUARIO CREADOR. Fecha entrega 12 de junio de 2014 Revisión 1.0
SAP SOLUTION MANAGER 7.1 Service Desk MANUAL DE USUARIO CREADOR Fecha entrega 12 de junio de 2014 Revisión 1.0 CONFIDENCIALIDAD El material contenido en este documento y sus anexos representa información Más detalles Tema 1: Introducción a la gestión y planificación de redes
Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de Más detalles Service Desk Institute Latinoamérica. La importancia de un diagnostico eficaz Registración y derivación
Service Desk Institute Latinoamérica La importancia de un diagnostico eficaz Registración y derivación CONTENIDO Service Desk la importancia del Diagnostico y la asignación Dentro del flujo del proceso Más detalles Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do.
Gobernabilidad de TI COBIT Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2do. Cuatrimestre 2010 T. 2 Contenido Introducción a la Gobernabilidad de TI Más detalles HELPPEOPLE CORE Boletín de la Versión 6.6.3.2 s38.2014
HELPPEOPLE CORE Boletín de la Versión 6.6.3.2 s38.2014 Elaborado por: Investigación y Desarrollo Helppeople Software Boletín de Versiones E ste boletín permite informar los cambios realizados en la aplicación, Más detalles ITIL FOUNDATION V3 2011
ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la Más detalles Rumboitil www.rumboitil.com e-mail: info@rumboitil.com
INDICE... Error! Marcador no definido. Unidad 3 Estrategia del Servicio... 2 3.1 Creación de Valor a través del Servicio.... 2 3.2 Gestión de la demanda.... 4 3.3 Gestión financiera.... 7 3.4 Procesos Más detalles Configuración de Servicios TI
Configuración de Servicios TI 1.- Identificar los objetivos del proyecto Creación de una Junta de Proyecto: Objetivos: El proyecto se mantiene dentro de calendario y presupuesto El proyecto consigue sus Más detalles ISO 19770 (SAM), por dónde empezamos?
ISO 19770 (SAM), por dónde empezamos? Qué es ISO/IEC 19770-1? La ISO 19770 se ha desarrollado a fin de permitir a una organización demostrar que está efectuando la gestión de activos de software, comúnmente Más detalles Estandares y Normas. Universidad Tecnológica Nacional -FRBA

References: Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución