// // 3 comentarios

Cómo contradecir a tu jefe sin quedar mal

¿Cómo decirle no a tu jefe? - Consultoria-SAP.com

En el largo periodo que llevamos brindando respuestas a distintas consultas sobre SAP, me ha tocado leer que los jefes piden cosas totalmente "locas" y los consultores SAP se ponen a investigar cómo hacer los escenarios que piden. En el 90% de los casos, por no decir en el 99%, los jefes piden sin darle el suficiente análisis, ni hablar de los usuarios que se podría afirmar que en el 100% de los casos piden cosas a los consultores SAP que son directamente imposibles, o bien esperan que SAP haga cosas por arte de magia.

En este artículo profundizaré la "cintura" que debemos tener los consultores SAP para contradecir a nuestros jefes, o mejor dicho, para decir "no se puede", "lo que pides es una locura", "por qué pides eso?", "puedes justificarme la necesidad de tu petición?", etc.

Si bien es un campo muy subjetivo, y dependerá muchísimo de qué persona nos pida las cosas, si esa persona está o no calificada, el grado de experiencia en SAP, etc etc etc... partamos del supuesto básico e inevitable que se esconde en la frase (o regla?): "El que sabe, sabe, y el que no, es jefe". Es decir, nuestro jefe no sabe tanto como dice (o parece). 






Lo que pide el "Jefe" debe hacerse sin chistar

¿Por qué? 
Atrevanse a preguntarse por qué hacer eso, sin antes PENSAR y analizar el impacto que traerá al sistema hacer lo que el jefe ha pedido. ¿Quién crees que pagará los platos rotos cuando lo que ha pedido el jefe termine provocando inconsistencias en el sistema? ¿Tu jefe? 

Citemos el caso más reciente: #Consulta-SAP sobre agregar un campo nuevo al maestro de materiales, el jefe de Ricardo que nos dice:

(...) mi Jefe, así me ha comunicado: "Quiero agregar un nuevo campo al maestro de materiales".

Mi consejo aquí es simple, si van a hacer lo que el jefe pide, al menos por escrito (SIEMPRE POR ESCRITO) escriban un correo al jefe explicando que ustedes no recomiendan hacer lo que se ha pedido porque SAP no lo recomienda. Si quieren ser específicos, pueden citar URLs en el correo del sitio de SAP, o bien de ésta comunidad, donde con gusto más de un consultor SAP podrá discutir por qué las locuras que piden los jefes son refutables y brindar justificación oficial para vuestros atareados días de trabajo.

¿Por qué enviar un correo que exponga que el jefe no tiene razón?

Alguien aquí podría decirme o preguntarme si estoy loco, si no tengo "miedo" que me echen o quedar mal con mi jefe hará que se desgasten las relaciones (el clima laboral) y me termine perjudicando a largo plazo. Al contrario, si tu jefe tiene más de dos dedos de frente, valorará tu actitud de pensamiento lateral, tu "valor" para negarlo y tu capacidad de análisis a largo plazo, lo que hará que sumes punto para el futuro... 

Y suponiendo que tu jefe no tenga esos dedos de frente? Suponiendo que el jefe es un gilipo*** de esos que nunca faltan? Pues nada, a bancarse las balas con el pecho, por eso eres consultor SAP, estás al frente de SAP y eres responsable del sistema. No hagas lo que el jefe pide solo porque es tu jefe, piensalo dos veces, si no te cierra, pues PLANTEALO por escrito.

Una opción más light

Puedes ser sutil, y decir que no estás de acuerdo porque SAP no lo recomienda, pero al mismo tiempo darle la posibilidad de investigarlo si él así lo prefiere, y que harás pruebas de error en QAS (calidad), para ver qué tal va lo que ha solicitado.

Que tu jefe te diga lo que piensa ante las pruebas, no lo olvides. Por más que trabajes al lado del jefe, envíale un documento con los resultados de las pruebas!!! 

Lo importante es que todo quede por escrito

¿Por qué? Lo que está por escrito es tu garantía -y siempre lo será!, cuando alguien venga a buscarte y te pida explicaciones de por qué "el maestro de materiales" (como en este caso puntual que vemos aquí) no funciona como debería, tú podrás mostrarle un email impreso donde aclarabas a tu jefe que no estabas de acuerdo, pero sin embargo, tu jefe te lo solicitó y lo hiciste a solicitud.

Estará en cómo manejas la situación, quién es la persona que viene a "buscarte" y espero puedas tener la cintura para explicar que no tuviste alternativa a la solicitud de tu jefe.

Aunque con una mano en el corazón, espero que nunca te pase.
Si te piden locuras, es tu deber analizar y proyectar hacia delante el escenario, probarlo, y ver si el mismo es realmente útil, o si lo que piden es "cualquier cosa" (un mero sueño, una utopía, etc). 

No soy partidario de decir: "SAP NO PUEDE", o no se puede hacer eso en SAP. 
Por que la realidad es que con SAP, un buen consultor puede hacer lo que sea que se proponga.
Pero hay que saber aceptar los límites del estandar, para algo está ahí... es un límite., y hay que defenderlo. Somos nosotros, los consultores SAP quienes defienden el estándar! 




Creo que me he ido un poco por las ramas.
Mis disculpas.

Espero le saquen provecho al artículo y sirva para abrir ojos.
Recuerden que si tienen dudas SAP, situaciones imposibles que le piden vuestros jefes (o usuarios), pueden unirse a la comunidad de ayuda SAP en español, y plantear libremente el tema sin miedo... ninguna de las personas que conforman la comunidad ha nacido sabiendo sobre este ERP, aquí todos aprendemos preguntando, y practicando!

Nos estamos leyendo.
Un fuerte abrazo,
SidV 



Post Data antes de que salten los consultores SAP MM expertos del maestro de materiales; tomé el ejemplo de lo que le solicitaron a Ricardo como un caso puntual. La realidad es que no estoy 100% seguro de que sea una "locura" agregar un campo "Z" al maestro, de hecho he trabajado con clientes SAP que tienen maestros "modificados" y tienen campos Zetas, así que deduzco que no es algo utópico ni una locura. Así que a esos consultores MM expertos, que me matarían por tomar este caso de ejemplo, les pido por favor que se unan en este debate para ayudar al amigo Ricardo, que necesita saber cómo agregar el campo al maestro de materiales =) 



3 comentarios:

  1. En ocaciones los consultores pecan de decir qe si a todo sin siquiera cuestionar un ppoco la desicion tomada, pero este post sirve para despertar conciencia en el trabajo diario, los consultores no solos son tecnicos que ejecutan, tambien deben asesorar y ser participes de las desiciones tomadas que afecten al sistema.

    ResponderEliminar
  2. Por mi experiencia personal como Ingeniero informático, que tenemos que hacer siempre una especificación de requisitos y un análisis antes de programar, es que por mucho que se planifique que las cosas van a ser de una forma, SIEMPRE va a cambiar, por eso aparecieron las metodologías ágiles y dinámicas de desarrollo. Hay que ser flexible, muy flexible, pero eso no implica el hacer todo lo que digan porque a veces son incoherencias. Si piden algo, hay que reunirse con el jefe para hablarlo detenidamente, y hacer de nuevo lo que se llama especificación de requisitos, decirle lo que implica y las horas de trabajo estimadas que conllevarán ese cambio.
    Hablando se entiende la gente.

    ResponderEliminar
    Respuestas
    1. Muchas gracias Jesus por compartir tu comentario, es excelente aporte.

      Eliminar

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


Para otras preguntas, por favor envíe su consulta aquí, es gratis!. Su consulta no molesta, le responderemos a la brevedad