Guía de Herramientas de Tickets para Expertos en SAP

Hola Prassana

Obtener una lista de herramientas de manejo de tickets a nivel de empresa es difícil, ya que solo una persona que trabaje en esa empresa lo sabría. Además, compartir esa información aquí no es aconsejable, ya que va en contra de las herramientas de la empresa. La más utilizada y comúnmente usada es Outlook. Aquí podemos asignar una tarea/ticket, generalmente el líder hace lo mismo. Si trabajas en Outlook por un tiempo con tareas, te familiarizarías con lo mismo.

Saludos

Hola Rajesh

Gracias por darme información

Necesito algunos boletos (altos)

y también una lista de herramientas por compañía.

Saludos

Prasannna

Las herramientas de ticketing varían de un cliente a otro. SAP también proporciona SAP Solution Manager, que también se utiliza como herramienta de ticketing.

Concepto general de tickets:

El manejo de tickets se llama sistema de seguimiento de problemas. Los errores o bugs enviados por el usuario final al equipo de soporte se priorizan en tres niveles de severidad: Alto, Medio y Bajo. Cada nivel de severidad tiene sus límites de tiempo antes de los cuales debemos corregir el error.

El trabajo principal del consultor de soporte es brindar asistencia en línea al cliente u organización donde ya se ha implementado SAP, para lo cual la persona debe ser muy sólida en el tema y en los procesos implementados en SAP en el lado del cliente para comprender, analizar, actuar y dar la solución correcta en el momento adecuado. Este es el trabajo del consultor de soporte.

Los problemas o tickets (problemas) que surgen son atendidos con prioridad por los consultores del equipo de soporte.

A continuación se describen los procesos de trabajo en proyectos de soporte para su referencia.

1. El cliente o el usuario final registra una llamada a través de cualquier herramienta o por correo (RADIX).

2. Cada miembro del equipo de soporte forma parte de un grupo de soporte.

3. Cuando un cliente registra una llamada, debe mencionar a qué grupo de trabajo pertenece (por nombre).

4. Una vez que las llamadas llegan al grupo de trabajo, el consultor de soporte o el equipo deben enviar una respuesta inicial (IR) al usuario dependiendo de la prioridad de las llamadas (Alta, Media, Baja, Ninguna).

5. Luego, el error es corregido, depurado por el consultor de soporte o el equipo. Después de probar adecuadamente generando una TR (Solicitud de transporte a través del administrador de base).

6. Luego se informa al usuario final/cliente/superusuario sobre los cambios que se han trasladado al servidor de producción mediante el proceso CTS.

Estos son los procesos. En resumen, lo que entiendo es que si se requiere alguna configuración o personalización para resolver el problema, entonces el consultor debe trabajar en el Cliente DEV, luego el usuario final lo probará en el Cliente QA y después de la aprobación el consultor BASIS debe transportarlo al Cliente de PRODUCCIÓN.

Un ejemplo:

Los tickets en SD pueden considerarse como los problemas que enfrenta el usuario final o el empleado de la empresa al trabajar en R/3. Los tickets suelen ocurrir durante la implementación o después de la implementación del proyecto. Pueden surgir numerosos problemas en el soporte de producción y la persona que trabaja en el soporte debe resolver esos tickets en un plazo limitado, cada ticket tiene una alerta de plazo específica, por lo que su responsabilidad es finalizarlo antes de ese plazo.

Para empezar, deberíamos darte un "TICKET" por no conocerlo.

Aquí tienes un ejemplo de un ticket levantado:

El usuario final no puede

1. Crear una orden de venta para un cliente desde una nueva planta, ya que no se ha realizado la determinación del punto de envío. (Sin el punto de envío, el documento queda INCOMPLETO y no podrá proceder más, como ENTREGA, FACTURACIÓN).

Él levanta un ticket y la prioridad se establece en uno de los siguientes:

1. Baja 2. Media 3. Alta.

Ahora debes resolver este ticket. Analizarías el problema e identificarías que la configuración del PE debe realizarse para la nueva planta.

Solicitarías un transporte para el CLIENTE DEV a BASIS. Realizas el cambio y solicitas un transporte adicional a BASIS para el cliente QA. El usuario final probará lo mismo creando una orden de venta para la nueva planta y lo aprobará.

Finalmente, solicitas un transporte para mover los cambios a PRODUCCIÓN. Una vez que el cambio se implementa en producción, el TICKET se cierra. Lo que he dado es un pequeño ejemplo. En tu soporte diario podrías encontrar problemas reales con severidad ALTA.

Saludos,

Rajesh Banka