You are on page 1of 115

ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN

PREPARADO Y COMPILADO POR: ING. CARLOS ALBERTO RODRIGUEZ RODRIGUEZ

VERANO DEL 2010.

UNIDAD 3: Soporte del servicio de tecnologías de información. 3.1 Introducción 3.2 El Centro de Servicios. 3.3 Gestión de los Incidentes 3.4 Gestión de los Problemas 3.5 Gestión de los Cambios 3.6 Gestión de las Versiones. 3.7 Gestión de las Configuraciones

3.1. INTRODUCCIÓN

El soporte al servicio se preocupa de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del servicio prestado al usuario. El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporte al servicio según los estándares ITIL:

INTRODUCCIÓN .3.1.

.

CENTRO DE SERVICIOS (SERVICE DESK) .2.3.

en su concepción más moderna. del Centro de Servicios es servir de punto de contacto entre los usuarios y la Gestión de Servicios TI. •Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes. aunque no único.1. •Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas. . •Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes. Un Centro de Servicios. CENTRO DE SERVICIOS (SERVICE DESK) El objetivo primordial. debe funcionar como centro neurálgico de todos los procesos de soporte al servicio: •Registrando y monitorizando incidentes.3.

Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad. Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que están recibiendo una atención personalizada y ágil que les ayude a: •Resolver rápidamente las interrupciones del servicio. •Informarse sobre el cumplimiento de los SLAs. •Recibir información comercial en primera instancia. eficiente y continuo e independiente de su localización geográfica. . •Emitir peticiones de servicio.

El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los servicios ofrecidos: Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios. Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio. . excepto en los casos más triviales. a otras instancias de soporte y/o comerciales.

. usuarios y la propia organización TI tales como: •Supervisión de los contratos de mantenimiento y niveles de servicio.Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. •Gestión de las licencias de software. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes. •Canalización de las Peticiones de Servicio de los clientes. •Centralización de todos los procesos asociados a la Gestión TI.

•Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo. •Soporte al servicio proactivo. .Los principales beneficios de una correcta implantación del Centro de Servicios se resumen en: •Reducción de costos mediante una eficiente asignación de recursos. •Apertura de nuevas oportunidades de negocio. •Centralización de procesos que mejoran la gestión de la información y la comunicación.

Estructura del centro de servicios Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda la organización TI con clientes y usuarios. . •Sirva de soporte al negocio. •Ofrezca un servicio de calidad consistente y homogéneo. •Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos. •Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica. es por lo tanto imprescindible que: •Sea fácilmente accesible.

. •Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios. •Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs. checklists... •Recibir formación sobre los productos y servicios de la empresa. •Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios.Estructura lógica Los integrantes del Centro de Servicios deben: •Conocer todos los protocolos de interacción con el cliente: guiones..

Estructura física Dependiendo de las necesidades de servicio: locales. 24/7. Existen tres formatos básicos: •Centralizado •Distribuido •Virtual .... globales.se debe de optar por una estructura diferente para el Centro de Servicios.

•Se simplifica la gestión. •Se optimizan los recursos. •Sin embargo surgen importantes inconvenientes cuando: •Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas. •Se necesita dar servicios de mantenimiento "onsite". productos y servicios. .Service Desk Centralizado En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura central. Sus ventajas principales son: •Se reducen los costos.

Service Desk Centralizado .

•Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks. sin embargo la deslocalización de los diferentes Centros de Servicios conlleva grandes problemas: •Es generalmente más caro. países o continentes). Sus ventajas son obvias en estos casos.Service Desk Distribuido Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades. . •Se complica la gestión y monitorización del servicio.

Service Desk Distribuido .

En un Service Desk virtual: •El "conocimiento" está centralizado. •Se puede ofrecer un "servicio local" sin incurrir en costos adicionales. •La calidad del servicio es homogénea y consistente. El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos. •Se evitan duplicidades innecesarias con el consiguiente ahorro de costos. .Service Desk Virtual En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de los Centros de Servicios puede llegar a ser irrelevante.

Service Desk Virtual .

La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service Desk. no cabe duda. .Actividades y Funciones Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de Servicios TI. de que su función principal es gestionar la relación con los clientes y usuarios manteniéndoles puntualmente informado de todos aquellos procesos de su interés. Sin embargo.

El éxito de su Service Desk es el éxito de su empresa" y el mismo depende en gran medida de las personas que lo integren. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante. Idealmente, el personal del Service Desk debe: •Compartir la filosofía de atención al cliente de la organización. •Comunicarse con corrección y buena educación y de una manera que el cliente pueda comprender. •Conocer en profundidad los servicios y productos ofrecidos. •Comprender las necesidades de los clientes y redirigirlos, si fuera necesario, a los expertos en cuestión. •Controlar todas la herramientas tecnológicas a su disposición para ofrecer un servicio de alta calidad. •Ser capaz de trabajar en equipo.

La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica. También es imprescindible el compromiso de la dirección con: •Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento. •Un continuo apoyo al equipo en la siempre difícil tarea del trato directo con los clientes. •El trabajo en equipo. •Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión.

3.3. Gestión de los incidentes

La Gestión de Incidentes no debe confundirse con la Gestión de Problemas.3. Gestión de los incidentes La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible. que existe una fuerte interrelación entre ambas. Sin embargo. pues a diferencia de esta última. no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. es obvio.3. .

.

El siguiente diagrama resume el proceso de gestión de incidentes: .

. o puede causar. una interrupción o una reducción de calidad del mismo”.Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es: “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente. lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias. etc. cambio de información de acceso. Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios. siempre que estos servicios se consideren estándar. .

•Mayor control de los procesos y monitorización del servicio. •Cumplimiento de los niveles de servicio acordados en el SLA. . •Una CMDB más precisa pues se registran los incidentes en relación con los elementos de configuración. •Optimización de los recursos disponibles.Los principales beneficios de Gestión de Incidentes incluyen: una correcta •Mejorar la productividad de los usuarios. •Y principalmente: mejora la satisfacción general de clientes y usuarios.

•Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente. . •Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes. •Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como: •Reducción de los niveles de servicio.

Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente. •No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado. •No están bien definidos los niveles de calidad de servicio ni los productos soportados. .Las principales dificultades a la hora implementar la Gestión de Incidentes resumen en: de se •No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.

. También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes.El nivel de prioridad se basa esencialmente en dos parámetros: •Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados. •Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente. la prioridad del incidente. Es conveniente establecer un protocolo para determinar. en primera instancia. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente: • .

.

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado. Básicamente hay dos tipos diferentes de escalado:
•Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema. •Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.

El proceso de escalado gráficamente como sigue:

puede

resumirse

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:

gestión de aplicaciones. el mismo Centro de Servicios o el soporte técnico. .Registro La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo. El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso. entre otros. Las incidencias pueden provenir de diversas fuentes tales como usuarios.

.. descripción del incidente.). o que pueda ser obtenida de la propia CMDB (hardware interrelacionado). •Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico. •Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo. •Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora. •Comprobación de que ese incidente aún no ha sido registrado: es frecuente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias. . etc.La admisión a tramite del incidente: •El Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente. sistemas afectados. •Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.

Análisis. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados. . Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Resolución y Cierre de Incidentes En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.

Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes.Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo. . Si fuera necesario se puede emitir una Petición de Cambio (RFC).

. •Reclasifica el incidente si fuera necesario. •Cierra el incidente. •Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente. •Incorpora el proceso de resolución a la KB.Cuando se haya solucionado el incidente se: Confirma con los usuarios la solución satisfactoria del mismo.

Estos informes deben aportar información esencial para. por ejemplo: •La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.CONTROL DEL PROCESO La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes. •Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente. .

•Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente. 3. . Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia. 2. Convertir el “know how” de los técnicos en un activo duradero de la empresa. Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet.Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar: •Un correcto sistema automatizado de registro de incidentes y relación con los clientes •Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Evitar escalados innecesarios. Una (KB) actualizada permite: 1.

4.3. Gestión de los problemas .

•Determinar posibles soluciones a las mismas. . •Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio. Gestión de los problemas Las funciones principales de la Gestión de Problemas son: •Investigar las causas subyacentes a toda alteración. del servicio TI.3.4. real o potencial. •Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.

. •Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.La Gestión de Problemas puede ser: •Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.

.

aún no identificada. Cabe diferenciar entre: •Problema: causa subyacente. .La Gestión de Incidentes. tiene como objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar las causas del mismo. Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones. de una serie de incidentes o un incidente aislado de importancia significativa. •Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas.

Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de Incidentes se resumen en el siguiente interactivo: .

. •Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.Las principales actividades de la Gestión de Problemas son el: •Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.

.

.El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

Sin embargo. se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema. . Identificación y Registro Una de las tareas principales de la Gestión de Problemas es identificar los mismos.El Control de Problemas se compone en esencia de tres fases: 1. Las principales fuentes de información utilizadas son: La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema.

Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes. la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas. .Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad.

. urgencia e impacto. entre otra. •Niveles de prioridad. cerrado. •Soluciones temporales.El registro debe incorporar. •Causas del problema. •Estado: activo. •Servicios involucrados. •Síntomas asociados. error conocido. información sobre: •Los CIs implicados.

se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio). Clasificación y Asignación de Recursos La clasificación del problema engloba desde las características generales de éste. que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo.2. que al igual que en el caso de los incidentes. . Un factor esencial es la determinación de la prioridad del problema. tales como si es un problema de hardware o software.

Análisis y Diagnóstico: Error conocido Los objetivos principales del proceso de análisis son: •Determinar las causas del problema.3. . •Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.

. Es frecuente que el problema este causado por: •Errores de procedimiento. entre diferentes .Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software.. •Documentación incorrecta. •Falta de coordinación áreas. •.

Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo.Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. en caso de aplicaciones desarrolladas "en la casa". o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión. . Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.

.Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.

. •Sus consecuencias sobre los SLAs. algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados. •Los costos asociados. siempre que esto sea posible.Identificación y Registro de errores El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado. Análisis y Solución Se deben investigar diferentes soluciones para el error evaluando en cada momento: •El posible impacto de las mismas en la infraestructura TI.

•¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable? •¿Los beneficios justifican los costos asociados? .Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones: •¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.

.Revisión Post Implementación y Cierre Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR). Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.

GESTION DE LOS CAMBIOS .5.3.

es frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona. Tendemos a asociar la idea de cambio con la de progreso. es evidente que toda "evolución a mejor" requiere necesariamente de un cambio. . y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias.3. no lo toques". Sin embargo. Gestión de los cambios Vivimos en una época de continuos cambios. puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados. Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas.5. y aunque esto no sea necesariamente así.

Las principales razones para la realización de cambios en la infraestructura TI son: •Solución de errores conocidos. . •Mejora de los servicios existentes. •Imperativo legal. •Desarrollo de nuevos servicios.

.

•Se ven reflejados en la CMDB. . •Han sido cuidadosamente testeados en un entorno de prueba. clasificados y documentados.La Gestión de Cambios debe trabajar para asegurar que los cambios: •Están justificados. •Están convenientemente registrados. •Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación. •Se llevan a cabo sin perjuicio de la calidad del servicio TI.

Las actividades principales de la Gestión de Cambios se resumen en el siguiente diagrama: .

•Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI. •Se evalúan los verdaderos costos asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión. algo imprescindible para la correcta gestión del resto de procesos TI. •Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".Los principales beneficios derivados de una correcta gestión del cambio son: •Se reducen los incidentes y problemas potencialmente asociados a todo cambio. •Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos. . •Se reduce el número de "back-outs" necesarios. •La CMDB está correctamente actualizada.

necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad. . •No se siguen los procedimientos establecidos y. independientemente de que este se realice para solucionar un problema.La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades: •Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio. •Los encargados de la Gestión de Cambios no conocen a fondo las actividades. no se actualiza correctamente la información sobre los CIs en la CMDB. servicios. en particular. mejorar un servicio o adaptarse a requisitos legales.

•Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio. •No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.•Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso. .

.

•Registrar. •Convocar reuniones del CAB. evaluar y aceptar o rechazar las RFCs recibidas. excepto en el caso de cambios menores. para la aprobación de las RFCs y la elaboración del FSC. .Las principales actividades de la Gestión de Cambios se resumen en: •Monitorizar y dirigir todo el proceso de cambio. •Coordinar el desarrollo e implementación del cambio. •Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

.

El primer paso del proceso de cambio es registrar adecuadamente las RFCs. . En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso. El origen de una RFC puede ser de muy distinta índole: Gestión de Problemas: se encarga de proponer soluciones a errores conocidos.

El origen de una RFC puede ser de muy distinta índole: Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad. Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados. .

a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM. por ejemplo. . software y/o procedimientos. y que por regla general requieren de cambios de hardware.El origen de una RFC puede ser de muy distinta índole: Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar. etc.

la LOPD (Ley orgánica de protección de datos para España). . cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura. Imperativo legal: un cambio de legislación (como. entre otros. puede exigir cambios en la infraestructura TI. Otro: en principio cualquier empleado.El origen de una RFC puede ser de muy distinta índole: Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización. por ejemplo. la obligación de emitir comprobantes digitales en México.

3. •Identificador único de la RFC. Tiempo estimado.Independientemente de su origen el correcto registro inicial de una RFC requerirá. •Identificador del error conocido asociado (dado el caso). Estimación de recursos necesarios para la implementación. •Descripción del cambio propuesto: 1. 4. 5. Motivación. •Estatus: que inicialmente será el de "registrado". cuando menos. 2. . de los siguientes datos: •Fecha de recepción. Propósito. CIs involucrados.

•Revisión post-implementación. •Evaluación preliminar de la Gestión del Cambio. •Evaluación final. •Planes de "back out". •Recursos asignados. •Fecha de implementación. •Fecha de cierre. La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos: •Estatus actualizado: "aceptado".Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. •Plan de implementación. "rechazado". •Cronograma. "implementado" •Fecha de aceptación (denegación) del RFC. •Prioridad y categoría. .

En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada. La aceptación del cambio no implica su posterior aprobación por el CAB (Consejo Asesor del Cambio) y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento.Aceptación Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. . Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición.

GESTION DE LAS VERSIONES .6.3.

6. . La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.3. Gestión de las versiones La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción.

. donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción. y el Depósito de Hardware Definitivo (DHS). donde se guardan copias de todo el software en producción.La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL).

.

Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio. . poner a prueba e instalar en el entorno de producción los cambios preestablecidos. La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión de Versiones el diseñar. Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI.

•Implementar las nuevas versiones de software y hardware en el entorno de producción tras su verificación en un entorno realista de pruebas. •Archivar copias idénticas del software en producción. •Asegurar. •Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente. en la Biblioteca de Software Definitivo (DSL). que todos los cambios se ven correctamente reflejados en la CMDB.Entre los principales objetivos de la Gestión de Versiones se incluyen: •Establecer una política de implementación de nuevas versiones de hardware y software. . •Mantener actualizado el Depósito de Hardware Definitivo (DHS). así como de toda su documentación asociada. en colaboración con la Gestión de Cambios y Configuraciones.

•Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado. •El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones. •Se reduce el número de copias de software ilegales.Los beneficios de una correcta Gestión de Versiones se resumen en: •El proceso de cambio se realiza sin deterioro de la calidad de servicio. •El correcto mantenimiento de la DSL impide que se pierdan (valiosas) copias de los archivos fuente. •Control centralizado del software y hardware desplegado. •Protección contra virus y problemas asociados a versiones de software incontroladas. . •Las nuevas versiones cumplen los objetivos propuestos.

Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente. .

según su impacto en la infraestructura TI. . etc. en: •Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad. •Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.Las versiones pueden clasificarse. •Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido. características técnicas.

2.0.0.Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique unívocamente. etc. etc. 1. Versiones menores: 1. Versiones de emergencia: 1. El sistema universalmente aceptado es: Versiones mayores: 1. 1.3. 1.1. etc. 2.1.1.1.2. .

pruebas.En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo. El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión: . producción y archivado.

Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no. . Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar: Versión delta: sólo se testean e instalan los elementos modificados. Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.

En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. por ejemplo.Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones. de esta forma se ofrece una mayor estabilidad al entorno TI. . en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos. Pensemos.

Las principales actividades de la Gestión de Versiones se resumen en: •Establecer una política de planificación para la implementación de nuevas versiones. el DHS y la CMDB. . •Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión. •Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario. •Actualizar la DSL. •Validar las nuevas versiones. •Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción. •Desarrollar o adquirir de terceros las nuevas versiones. •Implementar las nuevas versiones en el entorno de producción.

.

El rollout puede ser de varios tipos: Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos. Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo.La distribución de la nueva versión es también conocida como rollout. . introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.

que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.Tras la implementación. quejas. . la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los comentarios. etc. incidentes.

7.3. GESTION DE LAS CONFIGURACIONES .

Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB). Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión. 2. .3.7. Gestión de las configuraciones Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en: 1.

Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias. Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias. Interactuar con las Gestiones de Incidentes. Problemas . encontrar rápidamente la causa de los problemas. .3. 4. realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.

Las interacciones y funcionalidades de la Gestión de Configuraciones se resumen en el siguiente esquema: .

Servicios que ofrecen los diferentes CIs... a la Gestión de Incidentes. •Mantener actualizada la Base de Datos de Configuraciones: 1. estado.Los objetivos principales de la Gestión de Configuraciones se resumen en: •Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI. Interrelación entre los CIs. •Servir de apoyo a los otros procesos. 2. Problemas y Cambios.. 3. en particular. Registro actualizado de todos los CIs : identificación. . tipo. ubicación.

.Los beneficios de una correcta Gestión de Configuraciones incluyen. Una Gestión de Cambios más eficiente. entre otros: Resolución más rápida de los problemas. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema. drivers desactualizados. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas. etc. que redunda en una mayor calidad de servicio.

por ejemplo. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus. . Una CMDB actualizada permite. eliminar duplicidades innecesarias. detectar vulnerabilidades en la infraestructura. El conocimiento detallado de todos los elementos de configuración permite. etc. Control de licencias. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización. por ejemplo. Mayores niveles de seguridad.Reducción de costos.

Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible. .Mayor rapidez en la restauración del servicio.

monitores. etc. aplicaciones.. A modo de ejemplo citaremos: •Dispositivos de hardware como PCs. . . tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen. .Elementos de configuración (CI): todos. •Documentación: manuales. •Software: sistemas operativos.... lectores de CDs... teclados. acuerdos de niveles de servicio. . impresoras. routers. todos los componentes que han de ser gestionados por la organización TI. así como sus componentes: tarjetas de red. constituyen diferentes elementos de configuración. protocolos de red. En resumen.

. •Interrelaciones entre los diferentes elemento de configuración. por ejemplo. como. relaciones "padre-hijo" o interdependencias tanto lógicas como físicas La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización.Base de Datos de la Gestión de Configuraciones (CMDB): esta base de datos debe incluir: •Información detallada de cada elemento de configuración.

. nivel de profundidad y nomenclatura predefinidos.Las principales actividades de la Gestión de Configuraciones son: Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones. Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual. Clasificación y Registro: los CIs deben ser registrados conforme al alcance.

Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización. Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI. .