Saludos a todos, qué tema doloroso este. 
Acabo de leer un tema con la pregunta “¿Malos consultores de SAP?” … y tuve que reflexionar sobre nuestra reciente experiencia. Y decidí compartir algo de ella, apenas un poquito, pero espero que las ideas aquí expresadas ayuden a consultores y nuevos usuarios SAP a encarar de mejor manera el nuevo desafío.
Creo que un consultor no “nace”, se “hace” y de él depende si se hace bueno o se hace mediocre. (no voy a usar el término malo)
Estimados amigos(as) … me atrevo a iniciar este tema pues recientemente tuvimos una implementación SAP S/4HANA en nuestra empresa (grande en el país), con un alcance y tiempo desafiante para cualquier equipo de consultores. No era un proyecto sencillo -como al final ninguno lo es-, pero algunos proyectos se sacan el premio a la complejidad por la misteriosa conjunción entre estrellas y estrellados que conforman el equipo de proyecto.
Quiero compartir algunas lecciones aprendidas, sin ánimo de echarles palo a los consultores ni rosas a los clientes pues de ambas partes se tuvieron errores. Y sobre algunas cosas que a continuación voy a mencionar, muy posiblemente van a decir “pero si esto ya lo sabemos” … bueno , nosotros también creímos que lo sabíamos todo 
- El famoso “BBP”. CUIDADO CON EL ALCANCE. Si usted es usuario clave, describa lo mejor posible cada detalle de la implementación, en cada uno de los puntos, no suponga nada, la mente del consultor tiene una fortaleza difícil de derribar y se llama “
estándar SAP”, la mente del usuario tiene una fortaleza difícil de derribar y se llama “supuse que lo hacía”. Un BBP ambiguo es pelea segura.
Sr. usuario clave, asegúrese de entender MUY BIEN lo que NO HACE el estándar y describa lo mejor posible lo que DEBE HACER LA ADECUACIÓN para su caso particular.
Sr. consultor, asegúrese de entender muy bien LO QUE EL USUARIO QUIERE y asegúrese de que el usuario entienda muy bien LO QUE NO VA A TENER.
-
Arme un cronograma REALISTA. Que todos sepan claramente que lo que se quiere requiere tiempo.
Sr. consultor PMO, defienda su posición, sabe usted muy bien que a mayor alcance, mayor tiempo, mida bien sus fuerzas. Cuando el cliente quiere resultados en menos tiempo, encárguese de que se entienda que el alcance será menor. No ofrezca que logrará lo que el TITANIC no hizo. -
Invierta tiempo en capacitar a usuarios finales… ANTES, DURANTE y DESPUÉS del proyecto. El usuario debe saber lo que tendrá, cuándo lo tendrá y cómo lo usará. Cabe mencionar que el tema de capacitación fue el más crítico, nos dejaron EN PAÑALES.
Sr. consultor, el objetivo del proyecto es tener un cliente satisfecho que será un valioso aliado, no forme enemigos eternos.
– EL ANTES. La empresa debe invertir en capacitar a su equipo de usuarios clave Y SOPORTE TI, mucho antes que se empiece a escribir el BBP. Los que van a usar SAP, deben entrar al proyecto SABIENDO LO QUE SAP HACE Y COMO LO HACE.
– EL DURANTE. Deben identificarse claramente quienes son los usuarios que usarán la herramienta y comprometer su participación activa en las pruebas.
– EL DESPUÉS. Los gerentes de proyecto deben asegurarse que los que se quedan dando soporte al negocio (esos estimados y nunca bien ponderados analistas de TI de la empresa) tengan un buen plan de capacitación formal, a corto, mediano y largo plazo.
Sr. líder del producto, no reciba Key Users que al final no serán los que utilizarán o ejecutarán las transacciones en el día a día. Sr. consultor asegúrese de que las pruebas cubren TODOS los escenarios que se consideren periódicos y casos críticos.
Sr. consultor, le ruego
que enseñe al usuario a manejar adecuadamente sus transacciones, el pobrecito no sabe nada … tenga compasión de él.
Sr. Usuario, comprométase con el proyecto, estudie sus transacciones, apréndalas, escriba usted mismo sus ayuda memorias, practique con casos de uso diario que usted conoce.
Aporte con su tiempo y dedicación. NO DEJE SOLO A SU CONSULTOR.Pues el Sr. Experto hará lo que piensa que es suficiente y no hará aquello que solamente el usuario final sabe que es necesario.
- Deje un buen material de estudio. LA DOCUMENTACIÓN ES MUY IMPORTANTE. Sr. Consultor asegúrese de que el material es conocido por los usuarios.No es suficiente generar documentos, hay que transmitirlos. Explique los pasos en sesiones dedicadas, UTILIZANDO LAS HERRAMIENTAS DE DOCUMENTACIÓN, invierta tiempo en la enseñanza, cubra todos los casos, sea paciente, sea generoso, no deje 10 capturas de pantalla con 5 palabras como “guía del usuario”.
Un buen consultor no es el que “deja todo solucionado”, es el que prepara a sus usuarios para que puedan solucionar problemas cuando él ya no esté. El buen consultor es un diseñador, constructor, arquitecto, maestro y discipulador.
Bueno … ya me desfogué. Si los aburrí con la perorata, mil perdones.
Hay proyectos que dan para escribir libros … y al final de la historia, podemos terminar así: … CONTINUARÁ …
Claro … seguiré compartiendo lo que viene, para seguir aprendiendo juntos.
Saludos a todos … no hard feelings 