Impacto de Negocio en los casos
La importancia del impacto de negocio en los casos
Hola quiero aprovechar la newsletter para haceros llegar un mensaje que creo que os puede ayudar a conocer mejor el funcionamiento de la organización de soporte, además de a conseguir mejores resultados del servicio que ofrecemos.
Seguro que muchos de vosotros cuando habéis puesto un caso de soporte, habéis sido preguntados por el impacto que la situación reportada tiene en el negocio, e incluso en ocasiones después de que nos facilitéis esta información hemos insistido al respecto. Es posible que cuando os hacemos este tipo de preguntas penséis que lo que buscamos con ello es retrasar la solución o investigación del caso o que estamos buscando escusas para no resolverlo. Pero nada más lejos de la realidad.
Esta información es muy importante a la hora de escalar un caso y conseguir que se realice un parche. Los recursos disponibles son limitados y en muchas ocasiones hay que priorizar y realizar aquellos trabajos que van a impactar en un mayor número de clientes en detrimento de aquellos que sólo afectan a una situación o cliente específico. Aportando esta información demostráis que es importante que se invierta tiempo y recursos en la solución.
Un impacto de negocio básico puede ser la respuesta a las siguientes preguntas:
- Cuál es el negocio del cliente
- Cuántos clientes tienes afectados por el mismo escenario
- Porqué es importante que el escenario reportado funcione como esperáis
- Cuál es el proceso/requerimiento de negocio que hace necesario seguir este procedimiento
- Con qué frecuencia se produce el problema
- Cuáles son las consecuencias de que ese escenario no se solucione para el cliente y para el partner: políticas, económicas, fiscales…
Cuando escalamos un caso, éste tiene que pasar una primera evaluación en la que se valoran cuestiones como las siguientes:
- ¿Por qué este caso no ha sido escalado con anterioridad? Esta pregunta adquiere más peso aún, cuando el producto ha funcionado así a lo largo de diferentes versiones, y nadie hasta ahora lo ha reportado. Hay que tener en cuenta que si no ha afectado a nadie hasta hoy, implica que es un escenario muy atípico o aislado. Para responder a esta respuesta y defender la escalación se pueden utilizar argumentos como que no es fácil detectar el problema, lo que lo hace más peligroso porque puedes estar teniendo datos incorrectos y no ser consciente. También puedes enumerar las situaciones en las que se utiliza ese procedimiento para demostrar que sí es una práctica habitual en cualquier negocio. Pero en otras ocasiones es muy complicado de explicar las causas, con lo que las posibilidades de conseguir un parche se reducen considerablemente.
- Otra cuestión importante es la existencia o no de una solución alternativa. Si existe solución alternativa o "workaround" se reduce el impacto del caso, pues siempre se priorizan aquellos casos para los que en principio no hay modo de conseguir la solución esperada de ningún modo conocido. Para poder justificar la necesidad de solucionarlo, hay que aportar información explicando hechos como que con la solución alternativa sugerida se está perdiendo alguna funcionalidad, o bien, que el dejar el escenario reportado sin solucionar supone algún peligro.
Cuando hay riesgo de que un escenario no sea aceptado y no disponemos de este tipo de información o consideramos que no es suficiente, nosotros intentamos responder a las preguntas anteriores. Pero nadie mejor que vosotros, que estáis en contacto con el cliente afectado para aportarla. Lo primero porque sois los primeros interesados, y lo segundo porque tanto vosotros como vuestros clientes sois lo que mejor conocéis el negocio y los que mejor lo pueden explicar. Además vosotros tenéis acceso a un abanico más amplio de clientes así como a las vicisitudes de su día a día. Por todo esto, en muchas ocasiones tenemos que recurrir de nuevo a vuestra ayuda, para que nos proporcionéis información y es de más utilidad aún si esta información es facilitada anticipadamente.
Para finalizar, a continuación os facilito algunas recomendaciones a este respecto que considero pueden ayudaros a conseguir mejores resultados en vuestras escalaciones:
- Para clientes muy importantes rellenar una plantilla "Business case" aportando toda la información relevante, con datos económicos y políticos tanto del cliente como del partner para el que trabajáis. Dedicadle tiempo pues esta plantilla pues podrá ser reutilizada en los diferentes casos que tengáis para este mismo cliente. Esta plantilla es imprescindible para poder reabrir escenarios que previamente han sido ya rechazados, pero será muy útil en cualquier caso que se complique
- No dejéis de actualizar y solicitar actualizaciones al equipo de soporte, especialmente de los casos más críticos
- Solicitar la intervención de vuestro SAM. Los SAM os pueden ayudar a rellenar la plantilla, pero también a transmitir la urgencia e importancia de cada caso. También pueden ayudar a que los casos más lentos se agilicen.
- Ponderar la urgencia o criticidad de los casos. No todos los casos son críticos
- Comprender que en muchas ocasiones las solicitudes son auténticas faltas de funcionalidad o diseños que deben de ser modificados. Estos casos deben de ser solucionados por vuestros técnicos en modo de personalizaciones. Tened en cuenta que trabajamos para productos globales, que no pueden ser personalizados para un cliente concreto ya que afectarían a la generalidad que probablemente no esperan ese comportamiento.
- Nunca pongáis como impacto frases como "funciona mal y se espera que funciona bien", "el cliente quiere que funcione de esta manera", "es malo para la imagen del producto"… Aunque algunos de estos pensamientos son lógicos, no son útiles en este contexto, por lo que intentad ser prácticos y utilizar argumentos que nos ayuden a comprender y transmitir a los equipos de desarrollo la necesidad de solucionarlo.
Espero que este artículo os ayude a comprender un poco mejor cómo funcionan nuestros procesos así como a conseguir sacar el máximo partido de vuestros contratos de soporte.
Natalia Fernández de la Garma
Microsoft Dynamics AX Support Escalation Engineer