Conselhos para receber um serviço de suporte mais ágil com o Microsoft Dynamics utilizando o LCS
Tradução para o Português: Carlos Shimoda
* Dado que o serviço está centralizado nos produtos Microsoft, ficam excluídos do serviço quaisquer análises de dados e códigos customizados, incluindo produtos de terceiros (ex.: verticais do AX).
Uma vez que se reporta um incidente de suporte, este será analizado por um time de engenheiros, conhecidos como ‘Frontline’, os quais possuem um amplo conhecimento do produto. Caso seja necessária uma análise mais especializada, o incidente de suporte será escalado à um time de engenheiros conhecidos como ‘Backline’, os quais possuem conhecimento mais específico e profundo para cada uma das funcionalidades do produto. Se após esta análise existir a suspeita de que o comportamento possa se tratar de uma falha do produto (bug), o incidente será escalado ao time de ‘Escalation Engineers’ , os quais analizam o código e causas raiz do comportamento reportado. Por último, se escala ao time de ‘Program Managers’, os quais irão comparar o comportamiento reportado contra a especificação funcional e técnica do produto, e determinarão se o problema se trata do design planejado para o produto (by-design) ou de uma falha (bug).
O fluxo do processo anterior pode ser resumido na seguinte figura, considerando que a solução do incidente de suporte pode ser obtida (a qualquer momento) por qualquer um dos times envolvidos:
De modo que, para poder receber um serviço mais ágil e eficiente durante a resolução dos incidentes de suporte, se recomenda realizar o seguinte:
1. Fornecer informações precisas e completas
É extremamente útil e necessário contar com dados precisos e completos, tais como: versão do AX, Application build, banco de dados e Sistema Operacional.
O mesmo se aplica à informações a serem anexadas ao caso. Considerando que, nem sempre mais informação é melhor, somente informação necessária que ajude a reproduzir o problema com a finalidade de podermos analizá-lo.
Nota: é possível anexar até 3 arquivos de 5 MB cada.
Tenha sempre em mente que o engenheiro que irá trabalhar no incidente de suporte está fora do contexto do projeto onde o problema acontece. Portanto, é importante termos informações detalhadas que nos ajudem a entender e reproduzir o comportamento reportado (num ambiente diferente do cliente):
+ configuração do ambiente onde se apresenta o comportamento inesperado, e que esteja relacionada com o mesmo.
+ passo-a-passo do procedimento seguido até se obter o resultado atual, detalhado na medida do possível, mencionando: nomes dos formulários ou relatórios utilizados (e o caminho para se chegar aos mesmos), e parâmetros utilizados.
+ resultado esperado.
Dado que o engenheiro irá executar a análise em um ambiente standard (sem customizações), o que resulta em um serviço mais ágil e eficiente. Por isso recomendamos que antes de se reportar o problema, se execute o cenário num ambiente de testes (sem customizações). Recordando que o serviço está centrado nos produtos Microsoft.
Nota: é possível anexar prints dos formulários utilizadas, incluindo vídeo demonstrativo. Considere o uso do ’Gravador de tarefas’ (Task recorder) para documentar o procedimento, o qual foi apresentado no webinar ‘LCS Business process modeler Presentation’ (link abaixo).
https://mbs.microsoft.com/partnersource/latinamerica/support/support-news/latam_lcs_trainings
2. Redigir um Título claro e completo para o incidente de suporte (Issue Description)
Neste ponto, é importante contar com uma explicação do cenário de negócios onde ocorre o comportamento indesejado, ou seja, um resumo dos passos de reprodução.
3. Explicar o resultado atual e esperado (Actual Vs. Expected Result)
Neste ponto, é importante mencionar qual o resultado atual e esperado do AX. Se possível, e se for considerado necessário, incluir as razões (ou motivos) para se obter o resultado que se está esperando.
4. Detalhar os sintomas que levaram a reportar o problema (Symptoms that led to submission of this issue)
Neste ponto, responda à pergunta: “Como o usuário final está contornando esta situação, impossibilitado de obter o resultado esperado?”, ou “O que aconteceria se o usuário final, por algum motivo, não obter o resultado esperado?”
E detalhe em seguida (na medida do possível):
+ quando e com qual frequência ocorre o comportamento reportado.
+ a última vez que o AX funcionou conforme esperado.
+ atualizações recentes ou modificações no ambiente onde se apresenta o comportamento atual (configurações, hotfix, customizações).
+ se o comportamento atual pode ser reproduzido em ambiente standard (sem customizações), somente no ambiente do cliente, ou em nenhum outro ambiente.
A seguir, alguns exemplos de incidentes de suporte mal documentados vs bem documentados (com comentários).
Ex.: 1)
Descrição (Issue description): Erro ao gerar o relatório de reconciliação bancária.
Resultado atual vs Resultado esperado (Actual vs. expected result) : Se espera que o relatório mostre os dados corretos.
Sintomas que levaram a reportar o problema (Symptoms that led to submission of this issue): em branco.
Ao reportar este incidente de suporte, pode-se agilizar o atendimento fornecendo informações mais precisas como:
a. nome do relatório no AX (e caminho para se chegar ao mesmo).
b. exemplo do procedimento e parâmetros usados para gerar o relatório.
c. Resultado atual.
d. Resultado esperado.
Com estas informações, o engenheiro de suporte poderá analizar o comportamento do AX. Do contrário, seria necessário agendar uma sessão remota ou solicitar informações mais detalhadas (o que toma algum tempo) para então iniciar a análise.
Ex.: 1.a)
Descrição (Issue description): O relatório “Reconciliação bancária/do razão” (caminho: Contabilidade > Relatórios > Reconciliação > Banco) apresenta diferenças, as quais são geradas posteriormente à execução do processo periódico de “Reavaliação de moeda estrangeira” no módulo de Contabilidade, quando se tem o seguinte cenário de negócios:
1. executa-se um registro contábil numa conta bancária via Diário de contabilidade, em determinada data e moeda estrangeira.
2. executa-se o ajuste por tipo de câmbio, no módulo de contabilidade, numa data posterior (diferente da data do registro do diário e com tipo de câmbio diferente).
3. executa-se o relatório “Reconciliação bancária/do razão” e se observa diferença nos resultados.
Nota: no documento anexo registramos maiores detalhes como: tipos de câmbio históricos, configuração das contas de banco e contabilidade, valores usados no diário, parâmetros usados no processo periódico de ajuste por tipo de câmbio, bem como, caminhos dos formulários e prints do AX.
Resultado atual vs Resultado esperado (Actual vs. expected result):
A coluna “Diferença” deveria apresentar valor zero, sendo que, após análise das contas contábeis, identificamos que todas as transações bancárias encontram-se refletidas no módulo de Contabilidade.
Nota: no documento anexo registramos maiores detalhes dos valores obtidos no resultado atual e esperado, bem como prints do AX.
Sintomas que levaram a reportar o problema (Symptoms that led to submission of this issue):
Ao encontrar diferenças no relatório, o usuário final deve analisar os detalhes do saldo nas contas contábeis que apresentam diferenças. Esta análise é executada semanalmente, juntamente com a análise semanal das contas bancárias.
O relatório sempre se comportou desta forma.
Pode-se reproduzir em ambiente standard (sem customizações).
Ex.: 2)
Descrição (Issue description): O AX apresenta problemas de performance generalizados.
Resultado atual vs Resultado esperado (Actual vs. expected result): Que o AX não apresente lentidão.
Sintomas que levaram a reportar o problema (Symptoms that led to submission of this issue): em branco.
Ao reportar este incidente de suporte, pode-se agilizar o atendimento fornecendo informações mais precisas como:
a. apresentar uma única funcionalidade, característica ou relatório do AX onde possamos focar nossos esforços de análise e resolução.
b. exemplo do procedimento e valores usados.
c. última vez que o AX funcionou conforme esperado, bem como modificações/atualizações realizadas posteriormente.
d. tempo atual de resposta do AX.
e. tempo esperado de resposta do AX, e fatos que sustentem esse tempo, ou o tempo de resposta antes das modificações/atualizações realizadas.
Ex. 2.a)
Descrição (Issue description):
Ao faturar uma ordem de compra com mais de 2.000 linhas, dentro das quais existem dados adicionais como: impostos, descontos por acordos comerciais e encargos diversos, o AX registra a fatura em um tempo de 8 horas.
A ordem de compra é criada via customização através dos seguintes passos:
- Contas a pagar > Comum > Ordens de compra > Todas as ordens de compra
- Após carregar os dados da ordem de compra (via customização), se executa a Confirmação da mesma (tab Compra > botão Confirmar), posteriormente se executa o Recebimento (tab Receber > botão ‘Recebimento de produtos’), e finalmente se executa o Faturamento (tab Fatura > botão Fatura).
Resultado atual vs Resultado esperado (Actual vs. expected result):
Ao clicar no botão OK para lançar a ordem de compra, demora aproximadamente 8 horas para finalizar o processo. Para uma ordem de compra com 500 linhas, leva-se em torno de 5 minutos, então esperamos que para 2.000 linhas leve-se um tempo aproximado de 20 minutos.
Sintomas que levaram a reportar o problema (Symptoms that led to submission of this issue):
Nunca realizamos antes o registro de uma ordem de compra com essas características. Espera-se ingressar 5 ordens deste tipo durante os primeros 3 dias de cada mês. Atualmente este processo é executado durante os finais de semana (mas espera-se poder executá-lo durante a semana).
*** Nota: as situações e valores descritos são fictícios para fins de exemplo.
Estes são alguns conselhos, pois sabemos que nem sempre se têm todas as informações necessárias, porém quanto mais detalhes e claridade tivermos, mais rapidamente o engenheiro de suporte estará apto a iniciar a análise, com a finalidade de poder oferecer um serviço mais ágil e eficiente na resolução dos incidentes de suporte Microsoft Dynamics.
Muito obrigado por trabalhar conosco.