Problema de Tickets de Servicio (versin 2)

Escenario:
El escenario del problema de tickets de servicio cubre trminos de aseguramiento de la calidad o sobre equipos de soporte al cliente. Se identifica un bug o problema ; este problema debe registrarse; el registro debe revisarse para revisar su precisin; de una instancia del problema, se debe identificar la causa subyacente; se debe identificar la solucin, la cual debe comunicarse a la parte originadora del reporte.

El proceso:
Primero presentaremos una vista centrada en el proceso sobre en qu consiste el problema de tickets de servicio. Paso 1: Registrando el problema. El problema puede ser encontrado por una persona interna o externa. Hay dos formas de que el problema llegue de una persona externa: por telfono o por email. Para la persona interna, debe existir una pantalla que se muestre sin demora y que presente una forma para capturar los detalles del problema. Al enviar la forma se debe crear un proceso y asignarle un id. El id del ticket del problema debe generarse por el sistema y estar automticamente disponible (con un retraso no mayor a 10 segundos) para permitir que la persona externa conocer el ID del ticket del problema. El ID se utiliza como una forma de llamar el ticket de problema cuando esa persona llame de nuevo para comprobar el progreso. Por ltimo, un correo electrnico puede ser enviado a una direccin determinada. Este correo electrnico es automticamente recogido y se inicia un ticket de problemas, el cual incluye el cuerpo del correo electrnico como parte de los datos. No se intenta analizar automticamente el cuerpo del mensaje, pero la direccin del remitente de correo electrnico es recuperada del encabezado. El primer paso del proceso es que alguna persona interna lea el mensaje, completar algunos de los otros campos en el formulario con los valores reales, y luego enviarlo. El sistema debe ser capaz de buscar el usuario desde la direccin de correo electrnico. Cuando el ticket de problema sea enviado, una confirmacin por correo electrnico se enva a la persona externa, y el proceso va al paso 2. Paso 2: Reproducir el problema. Este paso est diseado para comprobar el informe del boleto de problema y para ver si describe con precisin un problema reproducible. Esta actividad es simplemente seguir las instrucciones en el informe y para ver si se produce el comportamiento descrito. Si el ticket de problema proviene de una persona interna, entonces, esta actividad deber ser asignado a otra persona para que la grabacin y reproduccin del problema no se hacen por la misma persona. Si se trata de una persona externa, esta actividad se puede realizar por la misma persona que entr el informe. Si el comportamiento no puede ser reproducido, entonces este proceso va al paso 3, de lo contrario va al paso 4. El problema puede ser identificado en esta etapa. Si hay una solucin conocida al problema debe ser ingresada o referida en esta etapa y se comunicar luego de nuevo al autor yendo al Paso 6. Si el problema es reconocido como un duplicado de otro problema, debe poder ser inscrito como tal y vaya al paso 5. Paso 3: Corrigiendo el reporte. Este paso slo se alcanza si el problema no puede ser reproducido. Este paso se asigna al autor si es interno. Si es externa, se debe asignar a una persona que puede comunicarse con el autor y obtener ms aclaraciones sobre el problema. Hay dos resultados de este paso, ya sea regresar a la etapa 2 o abandonar el proceso e ir al paso 6.

Paso 4: Identificar el problema y la solucin. Aqu es donde se llama al especialista. Los detalles del problema debe delimitar el rea del problema. Si el experto determina que el rea est mal, debera estar en condiciones de ser reasignado y se debe cambiar la persona destinada a la actividad. El problema permanece en este estado hasta que se determina una resolucin. O bien el problema se identifica y se corrige, o se corregir posteriormente debido a limitaciones de horario, o se determine que es un malentendido y en realidad es el comportamiento correcto. En todos los casos la resolucin debe ser comunicada al autor, ya sea por correo electrnico, o bien a travs de una llamada telefnica. Se va al paso 5. Para esta organizacin, el cumplimiento de esta actividad requiere la invocacin de una subproceso. El equipo de desarrollo tiene su propio proceso de flujo de trabajo que maneja esto de una manera que se adapte a su forma de trabajar. La ruta exacta de este sub-proceso no es objeto de este escenario, slo que se ha iniciado, se le da datos, y en algn momento ms tarde se informa de que est completo y devuelve un conjunto de datos. El subproceso para el equipo de desarrollo se implement antes que el escenario de ticket de problema, por lo que ya tiene un conjunto de condiciones con el significado apropiado a esa tarea. Esto significa que el proceso del ticket de problema debe traducir los campos al campo utilizado por el subproceso. Los detalles para esto se definen a continuacin. Paso 5: Comprobacin de la Resolucin. Cuando el problema se resuelve, entonces se espera a que la resolucin est disponible. Cuando lo est, la resolucin se verifica. Si la resolucin era "corregido" y el problema no est en realidad resuelto, el proceso puede ser enviado de nuevo al paso 4. De lo contrario el proceso va a paso 6. Paso 6: Comunicar los resultados. Aqu los resultados del proceso se comunican de nuevo al autor. Este paso contiene una regla segn la cual el resultado debe ser comunicado en un plazo de 3 das de ser conocido. Si no, se enva un mensaje de correo electrnico al Administrador de soporte. Paso 7: Auditora y Registro. Este paso puede suceder antes o despus del paso 6, pero tiene que ocurrir antes de que finalice el proceso. Se trata de que alguien busque en el proceso y determine si la pregunta / respuesta debe ser incluida en un boletn mensual para la comunidad de usuarios. Este paso se inicia en paralelo con el Paso 6 ya que no depende de l y podra pasar antes.