Guia de Ferramentas de Tickets para Especialistas em SAP

Olá Prassana

Obter uma lista de ferramentas de gestão de tickets a nível empresarial é difícil, pois apenas alguém que trabalhe nessa empresa saberia. Além disso, partilhar essa informação aqui não é aconselhável, pois vai contra as políticas da empresa. A mais utilizada e comumente usada é o Outlook. Aqui podemos atribuir uma tarefa/ticket, geralmente o líder faz o mesmo. Se trabalhares no Outlook por um tempo com tarefas, familiarizar-te-ás com o mesmo.

Cumprimentos

Olá Rajesh

Obrigado por me fornecer informações

Preciso de alguns ingressos (caros)

e também uma lista de ferramentas por empresa.

Saudações

Prasannna

As ferramentas de tickets variam de cliente para cliente. A SAP também fornece o SAP Solution Manager, que também é utilizado como ferramenta de tickets.

Conceito geral de tickets:

A gestão de tickets é chamada de sistema de rastreamento de problemas. Os erros ou bugs enviados pelo usuário final à equipe de suporte são priorizados em três níveis de severidade: Alto, Médio e Baixo. Cada nível de severidade tem seus limites de tempo antes dos quais o erro deve ser corrigido.

O principal trabalho do consultor de suporte é fornecer assistência online ao cliente ou organização onde o SAP já foi implementado, para o qual a pessoa deve ser muito sólida no assunto e nos processos implementados no SAP no lado do cliente para compreender, analisar, agir e fornecer a solução correta no momento certo. Este é o trabalho do consultor de suporte.

Os problemas ou tickets (problemas) que surgem são tratados com prioridade pelos consultores da equipe de suporte.

A seguir, são descritos os processos de trabalho em projetos de suporte para sua referência.

1. O cliente ou usuário final registra uma chamada através de qualquer ferramenta ou por e-mail (RADIX).

2. Cada membro da equipe de suporte faz parte de um grupo de suporte.

3. Quando um cliente registra uma chamada, deve mencionar a qual grupo de trabalho pertence (por nome).

4. Assim que as chamadas chegam ao grupo de trabalho, o consultor de suporte ou a equipe devem enviar uma resposta inicial (IR) ao usuário, dependendo da prioridade das chamadas (Alta, Média, Baixa, Nenhuma).

5. Em seguida, o erro é corrigido, depurado pelo consultor de suporte ou pela equipe. Após testar adequadamente, gerando uma TR (Solicitação de transporte através do administrador de base).

6. Em seguida, o usuário final/cliente/superusuário é informado sobre as alterações que foram movidas para o servidor de produção através do processo CTS.

Estes são os processos. Em resumo, o que entendo é que se for necessária alguma configuração ou personalização para resolver o problema, então o consultor deve trabalhar no Cliente DEV, em seguida, o usuário final testará no Cliente QA e após a aprovação o consultor BASIS deve transportá-lo para o Cliente de PRODUÇÃO.

Um exemplo:

Os tickets em SD podem ser considerados como os problemas que o usuário final ou o funcionário da empresa enfrenta ao trabalhar no R/3. Os tickets geralmente ocorrem durante a implementação ou após a implementação do projeto. Pode haver vários problemas no suporte de produção e a pessoa que trabalha no suporte deve resolver esses tickets em um prazo limitado, cada ticket tem um prazo específico de alerta, então sua responsabilidade é finalizá-lo antes desse prazo.

Para começar, deveríamos te dar um "TICKET" por não conhecê-lo.

Aqui está um exemplo de um ticket levantado:

O usuário final não consegue

1. Criar uma ordem de venda para um cliente de uma nova planta, pois a determinação do ponto de envio não foi feita. (Sem o ponto de envio, o documento fica INCOMPLETO e não pode prosseguir, como ENTREGA, FATURAMENTO).

...ele levanta um ticket e a prioridade é estabelecida como um dos seguintes:

1. Baixa 2. Média 3. Alta.

Agora você deve resolver este ticket. Você analisaria o problema e identificaria que a configuração do PE deve ser feita para a nova planta.

Você solicitaria um transporte para o CLIENTE DEV para o BASIS. Você faz a alteração e solicita um transporte adicional para o cliente QA ao BASIS. O usuário final testará o mesmo criando uma ordem de venda para a nova planta e aprovará.

Finalmente, você solicita um transporte para mover as alterações para PRODUÇÃO. Uma vez que a alteração é implementada em produção, o TICKET é fechado. O que dei foi um pequeno exemplo. Em seu suporte diário, você pode encontrar problemas reais com severidade ALTA.

Saudações,

Rajesh Banka