Consejos para recibir un servicio más rápido de soporte en Microsoft Dynamics utilizando LCS
* Dado que el servicio está centrado en el producto de Microsoft, quedan excluidos del servicio, cualquier análisis de datos y de desarrollos a la medida, incluyendo productos de terceros (por ejemplo: verticales de AX).
Una vez que se reporta un incidente de soporte, éste es analizado por un equipo de ingenieros, conocidos como ‘Frontline’, quienes tienen un amplio conocimiento del producto. En caso de requerir un análisis más especializado, el incidente de soporte es escalado con un equipo de ingenieros, conocidos como ‘Backline’, quienes tienen conocimiento más específico y profundo para cada una de las funcionalidades del producto. Si después de este análisis existe la creencia que el comportamiento pudiera tratarse de una falla del producto, el incidente se escala con el equipo de ‘Escalation engineers’ , quienes analizan a través del código, el segmento que ocasiona el asunto reportado. Por último, se escala con el equipo de ‘Program Managers’, quienes una vez que comparan el comportamiento reportado contra la especificación funcional y técnica del producto, determinan si se trata del diseño planeado para el producto o de una falla.
El flujo de proceso anterior se puede resumir en el gráfico que se muestra a continuación, considerando que la solución del incidente de soporte, puede obtenerse por cualquiera de los equipos involucrados:
De manera que, para poder recibir un servicio más rápido y eficiente en la resolución de los incidentes de soporte, se recomienda realizar lo siguiente:
1. Proporcionar información precisa y completa
Es de utilidad contar con datos precisos y completos, tales como: versión del producto, versión de la aplicación, versión de la base de datos y versión del sistema operativo.
Así como con la información adjunta al caso. Considerando que, no siempre mientras más información es mejor, sino incluyendo la información necesaria que ayude a reproducir el caso con la finalidad de poder analizarlo.
Nota. Es posible adjuntar hasta 3 archivos de 5 MB cada uno.
Considere que el ingeniero que analizará el incidente de soporte, está fuera del contexto del proyecto en donde se generó. Por lo tanto, se aprecia tener información detallada que ayude a reproducir el comportamiento reportado en un ambiente diferente al del cliente, tal como:
+ La configuración que se tiene en el ambiente donde se presenta el comportamiento no esperado, y que esté relacionada con el mismo.
+ El paso a paso del procedimiento que se ha seguido hasta llegar al resultado que se tiene actualmente, pero que no se espera, tan detallado como le sea posible, mencionando: el nombre de las formas o reportes utilizados, la ruta para llegar a ellos, los valores utilizados.
+ El resultado que se espera del sistema
Dado que el ingeniero realizará el análisis en un ambiente estándar, es decir, sin desarrollos a la medida, se incrementa la posibilidad de recibir un servicio más rápido y eficiente, si previo al reporte, se realiza una prueba en un ambiente sin las personalizaciones desarrolladas. Recordando que el servicio está centrado en el producto de Microsoft.
Nota. Es posible adjuntar imágenes de las formas utilizadas, o incluso un video demostrativo. Considere el uso del ’Grabador de tareas’ (en inglés ‘Task recorder’) para documentar el procedimiento, el cual se mostró durante la presentación ‘LCS Business process modeler Presentation’, la cual puede encontrarla en la siguiente liga https://mbs.microsoft.com/partnersource/latinamerica/support/support-news/latam_lcs_trainings .
2. Redactar una Descripción clara y completa para el incidente de soporte (Issue Description)
En este punto, se aprecia contar con una explicación del escenario de negocio en el que ocurre el comportamiento no esperado por el producto, o bien, un resumen de los pasos de reproducción.
3. Explicar el resultado que se tiene actualmente y el resultado que se espera (Actual Vs. Expected Result)
En este punto, se espera que mencione cuál es el resultado actual que observa en el producto, y cuál es el resultado que se esperaría del producto. De ser posible, y de considerarlo necesario, incluir la razón del resultado que está esperando.
4. Detallar los síntomas que llevaron a reportar el caso (Symptoms that led to submission of this issue)
En este punto, responda a la pregunta: ¿Qué hace el usuario final actualmente sin tener el resultado que se espera del producto?, o bien, ¿Qué pasaría si el usuario final, por alguna razón, no llegara a tener el resultado esperado en AX?
Y detalle, en la medida de lo posible, lo siguiente:
+ Cuándo y con qué frecuencia ocurre el comportamiento reportado.
+ La última vez que el sistema funcionó como se esperaba.
+ Actualizaciones recientes o cambios en el ambiente donde se presenta el comportamiento actual (configuración, hotfix, desarrollos a la medida).
+ El comportamiento actual se puede reproducir en un ambiente estándar (sin desarrollos a la medida), únicamente en el del cliente, o en ningún ambiente se puede reproducir.
Nota. La redacción puede hacerla en español o castellano.
A continuación, se muestran unos ejemplos, que permitirán contrastar una incidencia de soporte que tiene mayor posibilidad de recibir un servicio más rápido de soporte y una que podría no ser así.
Ejemplo 1.
Descripción: Error al emitir el reporte de conciliación de bancos.
Resultado actual vs Resultado esperado: Se espera que el reporte muestre datos correctos.
Síntomas: Vacío.
Al reportar ese incidente de soporte, se podría mejorar la posibilidad de recibir un servicio más rápido de soporte, proporcionando información precisa de lo siguiente:
a. Nombre del reporte y de la ruta para llegar al mismo.
b. Ejemplo del procedimiento y los valores registrados previamente a generar el reporte.
c. Valores utilizados para generar el reporte.
d. Resultado que obtiene actualmente del reporte.
e. Resultado que esperaría tener del reporte.
Con esa información, el ingeniero de soporte, podrá analizar el comportamiento del producto. De lo contrario, sería necesario coordinar una sesión remota o solicitar información más detallada para iniciar el análisis.
Ejemplo 1.a
Descripción (Issue Description):
El reporte de “Conciliación bancaria/contable” (Ruta. Contabilidad general > Reportes > Conciliación > Banco) muestra diferencias, las cuales son generadas posterior a ejecutar el proceso periódico de “Revalorización de moneda extranjera” en el módulo de Contabilidad General, cuando se tiene el siguiente escenario de negocio:
1. Se realiza un registro contable a un banco mediante un Diario contable en determinada fecha en moneda extranjera.
2. Se realiza el ajuste por tipo de cambio, desde el módulo de contabilidad a determinada fecha, diferente de la fecha del registro del diario contable y con un tipo de cambio diferente.
3. Se muestra el reporte “Conciliación bancaria/contable” y se observa una diferencia en el reporte.
Nota. En el documento adjunto se describe mayor detalle de valores, tales como: tipos de cambio históricos, configuración de las cuentas de banco y de contabilidad general, montos en el diario de contabilidad registrado, parámetros para realizar el proceso periódico de ajuste por tipo de cambio, así como, rutas de las transacciones utilizadas e imágenes del sistema.
Resultado actual vs Resultado esperado (Actual Vs. Expected Result):
La columna “Diferencia” debería mostrarse en cero. Esto es porque después de un análisis de las cuentas contables, se demuestra que todas las transacciones del banco se han reflejado en el módulo de la Contabilidad General.
Nota. En el documento adjunto se describe mayor detalle de los valores obtenidos en el resultado actual, los valores del resultado esperado, así como imágenes del sistema.
Síntomas que llevaron a reportar el caso (Symptoms that led to submission of this issue) :
Al encontrar diferencias en el reporte, el usuario final debe analizar el detalle del saldo en las cuentas contables que presentan diferencias. Este análisis se realiza cada semana al realizar un análisis semanal de bancos.
El reporte siempre se ha comportado de esta forma.
Se puede reproducir en un ambiente estándar (sin desarrollos a la medida).
Ejemplo 2.
Descripción: El sistema presenta problemas de performance generalizados
Resultado actual vs Resultado esperado: Que el sistema no sea tan lento.
Síntomas: Vacío.
Al reportar ese incidente de soporte, se podría mejorar la posibilidad de recibir un servicio más rápido de soporte, proporcionando información precisa de lo siguiente:
- a. Una única funcionalidad, característica o reporte del producto en el cual se deba enfocar el esfuerzo a realizar, en el análisis y resolución de la incidencia de soporte.
- b. Ejemplo del procedimiento y los valores que se utilizan en la funcionalidad, característica o reporte en cuestión.
- c. La última ocasión en que el sistema funcionó como se esperaba, así como los cambios que se realizaron posteriormente.
- d. El tiempo actual de respuesta del producto.
- e. El tiempo esperado de respuesta del producto y la razón de este tiempo, o bien, el tiempo de respuesta antes de los cambios en el producto.
Ejemplo 2.a
Descripción (Issue Description):
Al facturar una orden de compra con más de 2,000 líneas, dentro de las cuales existen datos adicionales, tal como: impuestos, descuentos por acuerdos comerciales y cargos misceláneos, el sistema registra la factura en un tiempo de 8 horas.
La orden de compra se ingresa mediante un desarrollo a la medida de carga en la siguiente ruta:
Cuentas por pagar > Común > Órdenes de compra > Todas las órdenes de compra
Después de ingresar los datos de la orden de compra, con el desarrollo de carga, se realiza la Confirmación de la misma en el Menú Compra (Botón ‘Confirmar’), posteriormente se Recibe en el Menú Recibir (Botón ‘Recepción de producto’) y finalmente se factura en el Menú Factura (Botón ‘Factura’).
Resultado actual vs Resultado esperado (Actual Vs. Expected Result):
Al presionar el botón Factura, el registro toma hasta 8 horas. En una orden de 500 líneas, se utiliza un tiempo de 5 minutos, por lo que se esperaría que el sistema tomara alrededor de 20 minutos en registrarla.
Síntomas que llevaron a reportar el caso (Symptoms that led to submission of this issue) :
Nunca se había realizado el registro de una orden de compra con esas características en ningún otro ambiente.
Se espera ingresar 5 órdenes de compra con estas características durante los primeros tres días del mes. Actualmente se ingresan durante el fin de semana, pero se esperaría poder ingresarlas entre semana.
*** Nota. Las situaciones y valores descritos arriba son ficticios para fines de documentación del blog.
Estos son únicamente algunos consejos. Sabemos que no en todos los casos se tiene toda la información que les gustaría tener, pero se aprecia contar con la mayor información posible que ayude al ingeniero de soporte a realizar el análisis, con la finalidad de poder ofrecerle un servicio más rápido y eficiente en la resolución de los incidentes de soporte de Microsoft Dynamics.
Muchas gracias por trabajar con nosotros. Y muchas gracias por su preferencia.
Para PP