MantSoft AE. Método para el mantenimiento de Software de Alhambra-Eidos. Gestión de incidencias en el mantenimiento correctivo.

Transcripción

1 MantSoft AE Método para el mantenimiento de Software de Alhambra-Eidos Gestión de incidencias en el mantenimiento correctivo.

2 Introducción Este documento describe el tratamiento específico que se le da a una nueva incidencia de acuerdo al Método de mantenimiento de software de Alhambra-Eidos (MantSoft AE). La incidencia reportada, que puede ser un incidente o una solicitud de servicio, es remitida por el cliente al Service Desk de Alhambra-Eidos. De acuerdo a lo especificado en el Acuerdo de Nivel de Servicio (SLA), la misma puede ser trasmitida a través de una llamada al número de soporte, o un a la dirección de correo electrónico creada para ello. A continuación se detalla el proceso completo de una incidencia del servicio de mantenimiento de software de acuerdo a MantSoft AE. Este proceso variaría atendiendo a lo especificado y acordado en el SLA específico de cada servicio de mantenimiento. Entorno de trabajo El gestor del servicio y el equipo de mantenimiento de Alhambra-Eidos tratarán las incidencia utilizando Outlook y CRM AE, por lo que deberán tener instalado el conector de Outlook para Microsoft Dynamics CRM. Tanto los técnicos del equipo de mantenimiento como el gestor del servicio, estarán dados de alta en el CRM AE de Alhambra-Eidos con los roles correspondientes. Los clientes del servicio de mantenimiento también estarán dados de alta en CRM AE con los datos con que están registrados en el ERP de Alhambra-Eidos (Infinity). Al estar dados de alta en CRM AE, el Service Desk de Alhambra-Eidos comprobará que la dirección de correo electrónico de los contactos del servicio sea correcta. Los clientes no tienen interacción directa con CRM AE de Alhambra-Eidos. Basado plenamente en Microsoft Dinamics CRMS, CRM AE ofrecer, basado en la experiencia de Alhambra-Eidos en proyectos de implantación de MS CRM, un entorno de implantación rápida gracias a que dispone de un conjunto de funcionalidades predefinidas, generalmente requerida por las empresas. CRM AE contiene las funcionalidades requeridas para trabajar con el método MantSoft AE para la gestión de incidencias en el servicio de mantenimiento de software.

3 Nueva incidencia. Ciclo de vida completo 1. El cliente al que se presta el servicio de mantenimiento remite la incidencia al Service Desk a través de una llamada al número de soporte, o un a la dirección de correo electrónico creada para ello. 2. El gestor del servicio, de acuerdo con el cliente, deberá concretar si se trata de un incidente o bien de una solicitud de servicio. Según SLA el cliente tendrá la obligación de enviar un documento, según sea la incidencia, utilizando la plantilla de reporte de error en la aplicación (incidente) o bien la plantilla de modificación de aplicativo (solicitud de servicio). 3. El gestor del servicio de mantenimiento de software registra la incidencia correspondiente en el CRM de Alhambra-Eidos. Por lo generar se parte del remitido por el cliente, por lo que desde Outlook se selecciona: Seguimiento en CRM AE/Establecer Referente a/caso/nuevo. Con esto se crea una incidencia/caso en la que se indican los siguientes datos: Incidencia: descripción básica de la incidencia Cliente: cliente al que se presta el servicio de mantenimiento de software Severidad: grado de importancia de la incidencia (alta, media, baja) Descripción: descripción detallada de la incidencia Estado: inicialmente En curso Tiempo estimado de la resolución Propietario: inicialmente el gestor del servicio Tipo de incidencia: es el tipo de mantenimiento, según lo acordado y detectado en el punto 2. En este punto se puede adjuntar un archivo si se considera necesario, por ejemplo, el documento que haya proporcionado el cliente a la hora de notificar la incidencia. Primero se debe guardar la nueva incidencia, y luego adjuntar el fichero correspondiente. 4. Una vez creada la incidencia el gestor del servicio la asigna al técnico responsable de la misma, indicando en el estado En curso. Esto enviará un correo automático al técnico para indicarle que tiene asignada la incidencia. 5. El propietario de la incidencia, el técnico del equipo de mantenimiento, debe aceptar la incidencia, para ello debe cambiar su estado a Aceptada. Si el técnico acepta la incidencia, se enviará un correo de forma automática al gestor del servicio y al cliente, para indicar que se ha comenzado ya a trabajar en la incidencia. En el correo enviado al cliente se le indica el ticket de la incidencia, así como el tiempo estimado de resolución de la misma, si procede. Este correo se enviará al cliente sólo la primera vez que se acepte la incidencia, no se enviará en el caso de que la

4 aceptación de la misma venga desde un estado de incidencia no validada, es decir, si se viene desde el punto 9 o 10 no enviará correo al cliente. En el caso de que el propietario de la incidencia no pueda iniciar su resolución, deberá cambiar el estado a Rechazada. Esto enviará de forma automática un correo al gestor del servicio, que deberá pasar al punto 4 para asignar un nuevo propietario y cambiar el estado de la incidencia a En curso. 6. El gestor del servicio deberá ir informando al cliente si existe algún cambio en el estado de la incidencia y en general de la evolución de la misma, indicando siempre el código correspondiente. Así mismo, tanto el propietario de la incidencia como el gestor del servicio, podrán ir indicando información adicional sobre la incidencia. Para ello se puede utilizar el apartado Actividades de la incidencia dentro de CRM AE. 7. El tiempo empleado en la resolución de la incidencia debe ser imputado como parte de trabajo dentro de Infinity. A la hora de introducir los datos del parte de trabajo, en el campo Acción se debe indicar el código de la incidencia (ticket), y en el campo descripción, una descripción breve de la tarea realizada. 8. Una vez resuelta la incidencia por parte del técnico del equipo de mantenimiento, deberá cambiar su estado a Resuelta, esto enviará un correo automático al gestor del servicio. 9. El gestor del servicio debe validar el correcto funcionamiento de la incidencia que se ha resuelto. Normalmente se dispondrá de un entorno de preproducción para realizar estas pruebas. Si el funcionamiento no es correcto, el gestor del servicio debe cambiar el estado de la misma a No validada y asignar de nuevo la incidencia al técnico. El orden desde CRM AE deberá ser el siguiente: asignar la incidencia al técnico, cambiar el estado a No validada y guardar. Esto nos llevaría al punto 5, en el que el técnico debe aceptar la incidencia. Si por el contrario, el funcionamiento es correcto, el gestor del servicio debe cambiar el estado de la incidencia a Validada y asignar al técnico como propietario de la misma. El orden desde CRM AE debe ser como el indicado anteriormente. Ahora el técnico deberá desplegar la resolución de la incidencia en el entorno que corresponda. 10. Atendiendo al SLA y al esquema de servicio en concreto, el equipo de mantenimiento desplegará el entregable que resuelve la incidencia en el entorno correspondiente, o también, según SLA el documento de despliegue. Y según el caso en concreto se realizará el despliegue en entorno de producción o en entorno de preproducción.

5 Una vez realizada esta tarea por parte del equipo de mantenimiento el técnico propietario de la incidencia deberá cambiar su estado a desplegado. Esta acción enviará un correo automático al cliente para indicarle que la incidencia ha sido resuelta y que debe validar el correcto funcionamiento de la misma (en el entorno que corresponda). 11. El cliente debe validar la correcta resolución de la incidencia. Según SLA el gestor del servicio de mantenimiento le deberá proporcionar al cliente un documento de pruebas. Si el cliente no valida la incidencia (incidencia resuelta de forma incorrecta), el gestor debe cambiar el estado de la misma a No validada y asignar de nuevo la incidencia al técnico. El orden desde CRM AE deberá ser el siguiente: asignar la incidencia al técnico, cambiar el estado a No validada y guardar. Esto nos llevaría al punto 5, en el que el técnico debe aceptar la incidencia. 12. Una vez que el cliente ha validado la resolución de la incidencia, el gestor del servicio deberá proceder al cierre de la misma. Para realizar el cierre de la misma se tiene que haber imputado, por parte del equipo de mantenimiento y por parte del gestor del servicio, todo el tiempo empleado en la resolución de la incidencia en Infinity a través de los partes de trabajo, y además validados completamente estos partes de trabajo por parte del gestor del servicio. Para cerrar la incidencia el gestor acude a Acciones/resolver caso dentro de CRM AE. Según se encuentre definido en el SLA, el cliente recibirá un informe indicando el tiempo empleado en la resolución de la incidencia y también el tiempo restante que queda por consumir del servicio. Atendiendo al caso, en el formulario de cierre/resolución de la incidencia, se seleccionará en el tipo de resolución No envío informe o Envío informe. CRM AE enviará en caso afirmativo el correo al cliente con el informe indicado.

6 Flujo de trabajo

7 Resumen de estados A continuación se ofrece un resumen de los distintos estados que puede presentar una incidencia cuando está activa: En curso: estado inicial. Se ha creado la incidencia pero no ha sido aceptada por ningún técnico. Aceptada: la incidencia ha sido asignada a un técnico y aceptada por el mismo. Rechazada: la incidencia ha sido asignada a un técnico y rechazada por el mismo, se tiene que volver a asignar a un técnico poniéndola en curso. Resuelta: la incidencia ha sido resuelta por el técnico y debe ser validada por el gestor del servicio. Validada: el gestor da por correcta la resolución de la incidencia, que deberá ser desplegada en el entorno que corresponda. No validada: el gestor o el cliente no da por correcta la resolución de la incidencia, se devuelve al técnico que deberá volver a aceptarla. Desplegado: la incidencia ya ha sido desplegada por el técnico, y está lista para que el cliente la valide. Si el cliente valida la incidencia, no habrá un nuevo estado, sino que el gestor debe cerrar la incidencia. Conceptos y acrónimos CONCEPTO Incidente Workaround Solicitud o Petición de Servicio Impacto Urgencia Prioridad SLA Grupos de soporte Gestor del servicio Infinity DESCRIPCIÓN un incidente es un evento que no forma parte de la operación estándar de un servicio y que causa o puede causar una reducción o interrupción en la calidad de servicio método de evitar un incidente o problema normalmente con una solución temporal cada llamada que no es un incidente, cambios en el servicio, peticiones de información, de documentación, etc. es el efecto que comúnmente tendrá un incidente en el negocio (número de afectados, magnitudes) valora la velocidad con la que un incidente o problema requiere ser resuelto la secuencia relativa en la que un incidente o problema necesita ser resuelto, basado en Impacto y Urgencia. Acuerdo de Nivel de Servicio grupos para la resolución del incidente (equipo de mantenimiento de la aplicación correspondiente) responsable del buen funcionamiento del servicio ERP de Alhambra-Eidos

8 Documentos relacionados Nombre del documento SLA Plantilla de reporte de error en la aplicación Plantilla de modificación de aplicativo Plantilla de plan de implementación DESCRIPCIÓN Acuerdo de Nivel de Servicio Contiene el detalle de una incidencia. Debe ser facilitada por el cliente (mantenimiento correctivo) Indicará una solicitud de servicio que se corresponderá con un cambio en la aplicación (mantenimiento evolutivo) Describe los pasos necesarios para desplegar el entregable que soluciona la incidencia correspondiente