// // 1 comentario

Consulta: ¿Documentar todo lo que el cliente pide?

Nos enviaron una consulta y nos rogaron que la dejemos anónima. Así que aquí estamos...

Situación inicial:

Nuestro consultor SAP ha estado trabajando más de un año con un cliente, ha implementado una solución, y ahora que el proyecto SAP terminó desde la consultora le han asignado que siga dando "soporte" al cliente.

  • Trabajamos en relación de dependencia (no somos freelancers)
  • Llevamos más de un año trabajando con la consultora
  • Experiencia en SAP: +5 años
  • Experiencia en Soporte / Mantenimiento: +10 clientes
  • Experiencia en Implementaciones / Rollouts: +7 clientes

La consulta en sí es: "Uno de los clientes que tengo asignado en mantenimiento me exige documentar el "paso a paso" de las incidencias -errores- que corrijo. ¿Eso es normal? ¿Hasta qué punto hacer lo que el cliente pide?"




Análisis de la situación:

Muchas dudas se han venido a la cabeza de quienes realizan este tipo de preguntas, ya que se supone que si el cliente "paga" por un servicio de mantenimiento (o soporte) SAP, espera que el consultor cubra todas las necesidades que aparecen durante el tiempo de contratación. Ahora bien, ¿hay límites? ¿El consultor SAP debe hacer todo lo que el cliente le indica? ¿Debe resolver todos los problemas que tienen a nivel de procesos? ¿Debe documentar paso por paso como ha solucionado los errores en el sistema? ¿Debe capacitar al cliente sobre cómo resolver las incidencias que le reportan? Y podríamos seguir haciendo preguntas durante todo este artículo, por lo que vamos a dejar un gran ETC abierto...

Seguramente hemos estado en esta situación. Estuvimos perdidos y dubitativos por largo tiempo, pues no sabíamos que hacer, que no hacer, dónde buscar ayuda, dónde buscar consejos. A quién escuchar.

Desarrollo / Solución:

Respecto a si lo que exige el cliente es normal; pues sí, es normal. El cliente es humano, y necesita "asegurarse" por así decirlo que lo que hacemos en el sistema esté bien, y que quede documentado es como su "garantía" de lo que hemos hecho. Ahora bien, habrá diferencias entre documentación de customizing o parametría y una documentación "paso a paso". 

Documentación de Parametría (o customizing)
Cuando un consultor SAP requiere acceso a un ambiente de desarrollo, y realiza cambios en la parametría del sistema, debe documentarse. Es una forma también de que el consultor tenga la "muestra o prueba" de lo que cambió (y cómo estaba antes -opcional). Esta documentación debe ser entregada al momento de cerrar la incidencia.

Documentación Paso a Paso
La documentación de este tipo se utiliza generalmente para manuales de capacitación donde los consultores brindamos todos los consejos y procedimientos -paso por paso valga la redundancia- para ejecutar ciertas transacciones dentro del sistema, y que dicha ejecución sea correctamente realizada para evitar que se produzcan errores y/o inconsistencias de información.

Resolución de Errores en Soporte SAP:
Si prestamos atención a los párrafos anteriores, hay diferencias muy claras entre un manual y otro. Cuando resolvemos errores en SAP, por lo general se requiere modificar algo en el sistema (lo que ha provocado el error del sistema). En ese caso, habrá que entregar la documentación de parametría, con los cambios que se realizaron al sistema, nada mas. No es necesario explicar porqué se hicieron esos cambios.

Qué ocurre si el error no es del sistema? Es decir, qué ocurre cuando el error es de procedimiento -humano- o bien el cliente está haciendo algo mal en sus procesos? Si fuese este el caso, y el cliente nos "asigna" el error como si fuese un error del sistema; tendremos que analizar el caso. 
En ese caso después de hacer nuestro análisis en los procesos, deberíamos explicarles cómo hacer las cosas para que funcionen correctamente en SAP. Ahora bien, esto no significa que tendremos que entregarle un documento que le indique al cliente lo que analizamos, cómo lo hicimos, porqué lo hicimos, y las conclusiones a las que llegamos.

Qué ocurre si el error se soluciona ejecutando una transacción o proceso que el cliente desconoce? Aquí es cuando la situación se complica. Por lo general, para llegar a la conclusión de que es una transacción o un proceso que el cliente no ejecuta bien (o desconoce), hemos realizado un análisis del sistema y de los procesos (y resultados buscados). Hay clientes que se conforman con un consultor que les indique cual es la "forma" de solucionar el caso, es decir, se ingresa a Solman (o herramienta por la que gestionen las incidencias), se coloca la transacción o una breve explicación de cómo deben hacerse las cosas en SAP para que el error no se produzca.

Buscar más opiniones:

  • Consultora SAP: si hablamos con la consultora que nos contrata, seguramente nos va a decir que tenemos que "cuidar al cliente" y de esa forma, tenemos que hacer todo lo que el cliente nos pide. Sin límites, mientras estemos dentro del horario laboral, el cliente debe recibir lo que ha pedido.
  • Consultores SAP: si hablamos con colegas, otros consultores, nos van a decir que tratemos llegar a un acuerdo., pero nunca documentemos la solución que ofrecemos a las incidencias, ya que tarde o temprano terminará el cliente solucionando sus propios problemas y prescindirán de los consultores. Siempre me recordaron que hay que solucionar incidencias, y no capacitar al cliente.
  • San Google: si googleamos en internet, encontraremos muchas páginas y blogs de freelancers que indican que el cliente NO siempre tiene la razón, pero como "nos contratan" tenemos que hacer lo que nos pide, aunque no nos guste; siempre teniendo en cuenta algunos límites, y si estos no existen, hay que negociarlos.
  • SCN de SAP.com: no he encontrado un buen debate en la comunidad oficial de SAP que nos explique qué consejos darían los gurúes SAP ante este problema. Así que voy a abrir un debate en ingles y otro en castellano, para ver qué opinan en SAP.com sobre este tipo de inconvenientes. :) 
Como podemos observar, hay muchas opiniones y como en todo, cuando chocan los intereses, cada participante defiende lo suyo. Los consultores SAP no querrán decir fácilmente o "enseñar gratis", mientras que el cliente cree que porque le paga a la consultora el servicio, es "dueño" del consultor y éste debe hacer lo que se le exige.

Negociar

Quizás lo mejor sea negociar, pero ¿con quién?
En este caso puntual, no se podrá negociar con el cliente, ya que el mismo ha negociado con la consultora que contrata al consultor SAP. Por tal motivo, el consultor tendrá que discutir este tema con sus jefes y ver si pueden llegar a un acuerdo que deje satisfechos a las partes (consultor SAP y cliente). 

Aprender a decir "NO"

Me ha pasado muchas veces, y he dicho "no". El cliente se enoja, y pone mala cara. Pero mientras el "no" sea bien justificado, tienes un 90% de probabilidades de ganar la pulseada. El cliente NO siempre tiene la razón. Muchas veces estaremos al frente de clientes que se abusan de su "poder" y quieren exprimirnos al máximo. Es parte de tu derecho y una obligación profesional saber cuales son tus límites y cómo decirle "no" al cliente.



Y tú? Qué harías en esta situación? ¿ Se te ocurre alguna otra forma de resolver este problema que enfrentamos en consultoría SAP ?
Aguardo tus comentarios


Algunas fuentes que he consultado para inspirarme y escribir este artículo:
Ojalá tengáis mucha suerte.
Saludos!

Pd: si quieres enviar tu consulta, puedes hacerlo al email de Contacto Consultoría-SAP.

1 comentario:

  1. Excelente artículo!
    Estoy 100% de acuerdo que el cliente no siempre tiene la razón, el problema está en saber manejar esa situación, ya que si uno lo plantea de mala manera es probable que no haya retorno.

    Voy a crear la discusión en forosap haciendo referencia a esta nota para ver que opinan los usuarios.

    Seguí así! :D

    ResponderBorrar

Nota Importante: los comentarios son para agradecer, comentar o sugerir cambios (o hacer preguntas) sobre el artículo de arriba.


SAP y el logotipo de SAP son marcas comerciales registradas de SAP AG en Alemania y en varios otros países. No estamos afiliados ni relacionados con ninguna división o subsidiaria de SAP AG.