Lo habitual en el mundo de la consultoría (y en casi cualquier ámbito profesional) es que la gente exprese su opinión cuando algo ha salido mal, cuando se sienten decepcionados o maltratados. Yo suelo hacer el camino inverso: me gusta poner en valor lo que funciona, lo que está bien. Porque eso ayuda más, a mí y al resto.
Hoy quiero hablar de la empresa con la que colaboro desde hace tiempo: Avvale.
Y es que Avvale es un buen sitio para trabajar, por muchas razones, entre ellas:
Saben lo que hacen: Saben hacer consultoría, preventa, gestión de proyectos y soporte al cliente. Y lo hacen bien. Hay algunas que solo saben facturar.
Saben cómo hacerlo: Avvale apuesta por la calidad y la eficiencia. Su modelo no consiste en llenar proyectos con 25 juniors, sino en ofrecer equipos ajustados, bien coordinados y orientados a resolver problemas reales..
La importancia del conocimiento: Su principal valor es su expertise profesional de su equipo, y lo hacen valer. El conocimiento se comparte, se valora, y se transmite. Si necesitas algo siempre habrá un experto al que consultar.
Gente buena y buena gente: en Avvale he encontrado grandes amigos, y también referentes en los que mirarme y aprender. Debo de tener suerte, pero lo cierto es que la gente con la que he trabajado es, además de excelente profesional, buena gente de verdad.
Avvale en Customer Experience CX
En lo que a mí respecta, Avvale es una de las consultoras más relevantes en el ámbito de Customer Experience (CX) en España. Cuenta con un equipo CX de más de 60 personas especializadas tanto en SAP como en Salesforce, y es líder en número de certificaciones SAP CX a nivel nacional.
Además, participa activamente en eventos del sector, mostrando soluciones, innovaciones y casos de éxito. Como en el último e-Show de Barcelona.
Belén Ballesteros, referente en SAP Emarsys (Abril 2025)
O en el pasado SAP CX Executive Exchange de la mano de Albia
David Mestre (Avvale) y Juan Muñoz (Albia) en el SAP CX Executive Exchange (Abril 2025)
Partner Gold de SAP
La relación entre Avvale y SAP —al menos en el área de CX, que es la que conozco de primera mano— es muy estrecha. Colaborar con Avvale significa tener un puente directo con SAP, acceder a conocimiento, participar en iniciativas y ganar visibilidad en el mundo SAP CX. La relación entre Avvale, SAP y los consultores es de ganancia mutua, jugando bien las oportunidades, todos ganamos.
Colaboración en contenidos
Como parte de nuestra colaboración, en los próximos meses vamos a publicar conjuntamente varios artículos enfocados en soluciones de Customer Experience, con el objetivo de ganar visibilidad mutua y demostrar que Avvale —y, por supuesto, yo con ellos— es el socio perfecto para acompañar a los clientes en su transición hacia herramientas modernas de CX.
En mi caso particular, participaré en la elaboración de contenidos centrados en SAP Sales & Service Cloud Version 2, una solución en la que estoy especializado y con la que trabajamos activamente en proyectos reales.
Eres el CIO de una empresa. En tu empresa habéis decidido hacer una transformación digital y dejar de una vez el ábaco y el Excel para llevar ventas, almacén, finanzas y costes y queréis implementar SAP como ERP de la empresa. Habéis lanzado la RFI (Request for Information) para pedir información, os han respondido tres consultoras medianas, tienen buena pinta, hacen hincapié en su experiencia, conocimiento y capital humano para afrontar un proyecto de implantación de SAP S4/HANA. Ninguna de las ¿grandes? ha contestado a la RFI.
Una de las consultoras (JOB Consulting), la que ha mostrado más interés y se ha preocupado por tus procesos, se presta a ayudarte a elaborar la RFP (Request for Proposal). Una vez consensuada con Negocio, TI y Dirección lanzas la RFP a las tres consultoras que te contestaron a la RFI y, aunque no se haya preocupado anteriormente, a una de las ¿grandes? (Deloitte, Accenture, NTT Data, IBM, Indra. Elige tu propia aventura).
The big 4
Las cuatro consultoras contestan a la RFP con su propuesta de solución, implementación y costes. La consultora que te ayudó a elaborar la RFP es la que mejor propuesta de valor ofrece. Hace referencia a procesos de tu negocio y da soluciones dentro de la herramienta elegida. Tiene casos de éxito, referencias, perfiles especializados, capital humano suficiente, solvencia en el mercado y un precio de implantación medio. Hay otras respuestas a la RFP más genéricas y más caras, más automáticas, sin tanto detalle por tu negocio. Tu invitado ¿grande? a la RFP mandó la respuesta fuera de plazo (bueeeno se lo admitimos), con carencias funcionales y bastante genérica, a nivel de músculo (financiero y capital humano) son, obviamente, el increíble Hulk. La oferta que ofrecen no cubre toda la funcionalidad de una vez, se presentan distintas fases de proyecto, solo dando precio a la primera, el producto mínimo viable (MVP). Obviamente el precio es muy bajo.
Producto Mínimo Viable (MVP) vs Producto Completo
No hay forma de comparar la respuesta de la consultora JOB Consulting y la ¿grande?. Tu yo interior, experto en tecnología y machacado en mil batallas lo tiene claro, la consultora JOB es la que más valor aporta y menos riesgo tiene a nivel tecnológico. Pero tú vas al consejo de administración, con el CEO y los distintos directores de área. Ellos expresan que no conocen a JOB, que sí conocen a la ¿grande?, pero que tu eres el CIO y delegan en ti la responsabilidad.
Pero esa reunión y ese dedo que te señala va calando en ti. ¿Y si sale mal? ¿Y si elijo a la consultora desconocida por el consejo y no va bien? Eres cobarde y te quieres aferrar al puesto porque vives en La Jaula de Oro. ¿A quien iban a despedir si va mal con la ¿grande?? ¿Quién se iba a imaginar que la ¿grande? pudiese fallar? El precio inicial es mucho más bajo pero, claro, solo incluye una parte, además no han participado muy activamente en la RFP.
Al final tu empresa decide (tú decides) contratar a la ¿grande? para hacer la implantación. El primer día aparece allí el socio, con el director y el manager, y te dejan una horda de 12 consultores de 25 años recien graduados, con uno que parece que más o menos sabe. Sabes que vas a sufrir, que los key uses del negocio van a sufrir, que tus usuarios van a sufrir, que el negocio va a sufrir, pero tu tomaste la decisión más coherente.
Tú observas la escena y te das cuenta de que has optado por lo que parecía la opción segura, la que el consejo reconocía, la que nadie cuestionaría en caso de fracaso. Sin embargo, una duda persiste en tu mente: ¿He elegido la mejor opción para el proyecto o solo la opción que me protege a mí?. Este es el dilema que enfrenta cualquier líder en tecnología cuando la reputación pesa más que el valor real.
Al final del proyecto, cuando todo esté en llamas, nadie te despedirá por contratar a la ¿grande?
… pero tampoco te felicitarían si hubieras tomado la decisión más valiente.
Hoy traigo Mitología Griega que me encanta, todo muy coherente con el sentido del blog (no). Bueno, veréis como sí tiene que ver con nuestra profesión (o cualquiera) y las motivaciones, debilidades y fortalezas humanas.
(Todas las imágenes han sido generadas con ChatGPT y Dall-E 3)
El Mito de Ícaro
Cuenta la leyenda de la mitología griega que Ícaro era el hijo de Dédalo, un talentoso inventor y arquitecto ateniense. Dédalo era famoso por haber construido el Laberinto en Creta, donde el rey Minos encarceló al Minotauro (esa es otra historia), una criatura mitad hombre y mitad toro.
Sin embargo, tras ayudar a Teseo a matar al Minotauro y escapar del Laberinto, Dédalo cayó en desgracia con el rey Minos. Como castigo, el rey Minos encerró a Dédalo y a su hijo Ícaro en una torre alta en Creta para evitar que escaparan y difundieran los secretos del Laberinto. Sin embargo, Dédalo, con su ingenio, ideó un plan para huir: construir alas hechas de plumas de aves y cera para Ícaro para poder volar sobre el mar y escapar de la isla.
Antes de iniciar el vuelo, Dédalo advirtió a Ícaro que no volara demasiado alto ni demasiado bajo. Si volaba demasiado bajo, el agua del mar empaparía las alas y lo haría caer. Si volaba demasiado alto, el calor del sol derretiría la cera que mantenía las plumas unidas.
Lleno de emoción por la experiencia de volar, Ícaro olvidó las advertencias de su padre y, embriagado por la sensación de libertad, comenzó a ascender cada vez más alto en el cielo. Al acercarse demasiado al sol, la cera de sus alas comenzó a derretirse, haciendo que las plumas se desprendieran. Sin posibilidad de mantener el vuelo, Ícaro cayó desde el cielo y se hundió en el mar, donde se ahogó. El lugar donde Ícaro cayó fue nombrado en su honor: el Mar Icario.
Reflexión sobre el Mito de Ícaro
La leyenda de Ícaro se puede interpretar como una advertencia sobre los peligros de la desmesura, el exceso de confianza y la desobediencia. La ambición de Ícaro lo llevó a ignorar los límites y las precauciones, lo que resultó en su caída.
Para mi, o sobre lo que yo quiero reflexionar en este artículo, es que hay que tener cuidado con la ambición, saber medir los riesgos, controlarse y controlarlos. Nada es gratis y, si intentas volar muy cerca del sol, es muy posible que te quemes.
Así que la próxima vez que sientas el deseo de volar más alto que nunca, recuerda que incluso el cielo tiene sus límites. Pero, claro, eso no significa que no debamos intentar volar.
El Mito del Ave Fénix
En un rincón lejano del mundo, mucho antes de que la humanidad pudiera siquiera imaginar criaturas fantásticas, existía un ser único, majestuoso y envuelto en misterio: el Ave Fénix. Era un ave radiante como ninguna otra, con plumas doradas y rojas que parecían llamas vivientes. Pero lo que hacía especial al Fénix no era solo su belleza, sino su increíble capacidad para renacer de sus propias cenizas.
Cuenta la leyenda que el Fénix vivía en un paraíso escondido, donde el tiempo pasaba de manera diferente. Su vida no era corta como la de otras aves, sino que duraba siglos. Sin embargo, el Fénix sabía que, al igual que todo en el universo, su tiempo también llegaría a su fin. Cuando empezaba a sentir el peso de los años y la fatiga en sus alas, el Fénix se preparaba para el gran momento: su renacimiento.
Cuando el tiempo llegaba, volaba hasta lo más alto del cielo y, desde allí, descendía en un vuelo majestuoso hacia su nido hecho de ramas de especias y plantas aromáticas. Una vez en su nido, el Fénix dejaba que las llamas lo envolvieran, ardiendo con un fuego brillante y purificador. Todo su cuerpo se consumía en ese fuego, hasta que no quedaba más que un montón de cenizas.
Pero aquí es donde ocurría el milagro: de esas mismas cenizas, entre el humo y el calor residual, nacía un nuevo Fénix, joven y lleno de vida. Con un poderoso aleteo, este nuevo ser emergía, más hermoso, con más energía y más resplandeciente que antes. Y así, una y otra vez, el Fénix vivía y moría, solo para resurgir con más fuerza.
Reflexión sobre el Mito del Ave Fénix
Resumen rápido: Cuando te caes, te levantas, aprendes y mejoras.
El mito del Ave Fénix es un poderoso mensaje sobre resiliencia, renacimiento y esperanza. El Fénix simboliza la capacidad de resurgir de las cenizas, incluso después de haber pasado por momentos de destrucción o pérdida.
Este mito nos recuerda que, aunque atravesemos dificultades, fracasos o situaciones dolorosas, siempre existe la posibilidad de volver a levantarse y comenzar de nuevo, renovados y fortalecidos.
¿Por qué cuento esto? ¿Qué relación tiene?
Bueno, digamos que es una reflexión personal que estoy contando en público. Es muy fácil convertirse en Ícaro, querer volar demasiado cerca del sol pero que tus capacidades, tu entorno, las alas que tienes o el destino donde quieres volar te hagancaer, y la caída esdura.
Pero es más difícil, una vez habiéndote convertido en cenizas, como el Ave Fénix, al volar tan cerca del Sol, resurgir de tus cenizas, aprender de los errores y hacer que ese tropiezo sea una lección aprendida que te haga resurgir con más fuerza, siendo más consciente de lo bueno que tienes y queriendo mejorar.
Volvemos a sentar las bases, en este caso, de lo que es un proyecto de implantación. Es posible que nunca hayas vivido un proyecto de implantación porque siempre has estado en mantenimiento, o que hayas entrado en uno que, o bien ya estaba empezado, o bien no se siguen las buenas prácticas a la hora de pasar por las distintas fases, generando la documentación necesaria en cada fase. Estas fases tan marcadas y secuenciales pertenecen a la metodología Waterfall de desarrollo de software que es la más común y la que hemos usado siempre. Otras metodologías como las Agile cambian estos paradigmas y la forma de realizar entregas, documentación y puesta en producción. Peto de Agile ya hablaré más adelante.
Un proyecto es como una carretera sinuosa, en muchos casos con tintes surrealistas.
No es necesario indicar que esta lista de fases, análisis, documentación y entregables es a máximos, no todo es imprescindible y, en muchas ocasiones, es imposible pasar por todo. Pero es lo deseable.
Fase 0: Etapa de Selección del Proveedor
Esta es la previa al proyecto pero, como veremos, es crucial. Si somos consultores participaremos en este proceso, o bien para sacar una oferta de funcionalidades que satisfagan los requerimientos, o incluso ayudando al cliente a crear la RFP.
🏢 Evaluación de Proveedores
Se analizan diferentes proveedores de SAP para evaluar su experiencia, capacidad, y compatibilidad con los requerimientos del proyecto. Esto se hace para acotar aquellos proveedores a los que se les quiere hacer la RFP.
📑 RFI (Request for Information)
Dentro del paso anterior se puede emitir un RFI (Request For Information) para recopilar información general sobre los proveedores. Se trata de un documento que las organizaciones utilizan para recopilar información básica de posibles proveedores de servicios SAP. Su propósito es obtener un entendimiento general de las capacidades y servicios que ofrecen distintos proveedores, ayudando a la organización a filtrar y seleccionar los que mejor se ajusten a sus necesidades específicas antes de solicitar propuestas más detalladas (RFP) o cotizaciones (RFQ). La RFI es un paso inicial importante para identificar los proveedores más adecuados para el proyecto.
📝 Assessment
Un proceso que puede solicitar un cliente, antes de la RFP, es que uno de los proveedores les ayude a estudiar sus procesos y elevar las necesidades de negocio. Como resultado de este proceso se generan documentos del AS IS (Cómo están los sistemas actualmente) y el TO BE (Qué es lo que se quiere).
Hay varios objetivos que puede tener esta fase:
Estimar a alto nivel costes futuros: Si tenemos que realizar un cambio tecnológico y necesitamos tener una magnitud de costes y tiempos de cara a preparar el presupuesto y a nuestro CEO del golpe que viene.
Identificar las posibilidades y poder comparar soluciones: El TO BE puede ser una comparativa de las soluciones que pueden ayudar a la empresa a realizar la evolución tecnológica. Por ejemplo, para satisfacer el AS IS y poder evolucionar a medio largo plazo en X negocio puedes usa SAP Sales Cloud V2 con estos PROS y estos CONTRA o Salesforce con estos PROs y estos CONTRAS.
Conocer el estado del sistema actual: Puede que tengamos un sistema infrautilizado, o con demasiados desarrollos propios y un mapa de integraciones loco.
📑 RFP – Request for Proposal
Este es el paso importante de la búsqueda de un proveedor desde el punto de vista del cliente. Se solicitan propuestas detalladas a los proveedores preseleccionados. Aquí se incluyen requisitos específicos del proyecto, plazos, y expectativas.
Desde el punto de vista del Proveedor la RFP es el documento de requerimientos (a muy alto nivel) sobre el que trabajar para presentar una oferta con la solución, plazos, perfiles, precio, etc.
¿Cuantas RFPs pasan por las manos de managers? Huelga decir que la persona o grupo de personas que realice la oferta necesita tener mucho conocimiento, de negocio, de las posibilidades de la herramienta, de esfuerzos necesarios (perfiles y costes), identificación de gaps o riesgos, etc.
📑 RFQ – Request for Quote
Cuando un cliente tiene muy claro lo que quiere, el alcance y cuando la funcionalidad a implementar es algo que no tiene discusión (Por ejemplo compra de Hardware), se genera un documento en el que la organización solicita cotizaciones específicas de proveedores potenciales. A diferencia de un RFP, que es más detallado y abarca cómo se abordarán los requisitos del proyecto, un RFQ se centra principalmente en el precio y los costos asociados.
Yo nunca me he encontrado con esta petición, puesto que no estoy en el departamento comercial y, lo que me llega a mi son RFPs para su análisis y preparación de la Oferta correspondiente.
🎯Respuesta al RFP
La oferta como tal. Pero no solo en términos económicos, sino como documento de análisis de los procesos y necesidades expresado en la RFP y propuesta de soluciones en la herramienta o herramientas seleccionadas. Incluye también, a alto nivel, estimación de tiempo, perfiles y esfuerzo. Y bueno, todo lo que se considere necesario para que el cliente lo lea y diga:
¡Está muy bien!
Fase 1: Preparación del Proyecto
En la Fase 1 de un proyecto de implementación de SAP, cada documento e hito tiene un propósito específico:
⚽ Kick Off
Como en los partidos de fútbol, el kick off es el evento que da comienzo el partido. Una vez contratado con un proveedor el proyecto, acordado el alcance y planificado las fases, tiempos y esfuerzos, comienza el partido.
Alguno empieza así el proyecto
✈️ Plan de Trabajo de Alto Nivel
Define la dirección general del proyecto, estableciendo los objetivos, el alcance y la estructura del equipo. Este documento es crucial para asegurar que todos los involucrados entiendan la visión y los objetivos del proyecto.
🛤️ Estudio de Viabilidad
Evalúa si el proyecto es técnicamente y financieramente viable. Incluye análisis de costos, recursos disponibles, y beneficios esperados, ayudando a tomar decisiones informadas sobre la viabilidad del proyecto.
🚑 Análisis de Riesgos
Identifica posibles riesgos asociados con el proyecto, evaluando su impacto potencial y proponiendo estrategias para mitigarlos. Este análisis ayuda a prevenir problemas futuros y planificar respuestas adecuadas.
⏳Especificación de Necesidades y Límites
Detalla lo que se incluirá en el proyecto. Esto implica definir los procesos y funciones que se necesitan mejorar o implementar con SAP, estableciendo así los límites del proyecto
👨💼👩💼Identificación de Actores
Se determinan todas las partes interesadas en el proyecto, asignando roles y responsabilidades. Esto incluye identificar a los miembros del equipo, los patrocinadores, los usuarios finales y otras partes relevantes.
Iñigo Montoya Consultor Senior SAP CRM
Fase 2: Business Blueprint
En la Fase 2, el enfoque principal está en mapear los procesos de negocio actuales, identificar las necesidades de adaptación y planificar cómo se configurará el sistema SAP para alinearse con estos procesos.
📋 Actas de Reunión
Durante la fase de Business Blueprint, se llevan a cabo múltiples reuniones con stakeholders y expertos en procesos empresariales. Las Actas de Reunión son esenciales para documentar las discusiones, decisiones y acuerdos realizados durante estas reuniones. Ayudan a asegurar que todos los detalles de los procesos de negocio y los requisitos del sistema estén claramente comunicados y acordados.
🏭 Business Blueprint (BBP) – Documentación de Procesos del Negocio
Esta es la piedra angular de la fase. Se documentan los procesos empresariales existentes y cómo se espera que funcionen con el nuevo sistema SAP. Este documento sirve como un mapa detallado que guía la configuración y personalización del sistema.
Me ha quedado bonita la caseta del perro. Quizás se ha pedido funcionalidad innecesaria para una caseta de perro.
📅Cronograma de Actividades
Desarrolla un plan de tiempo para el proyecto, estableciendo hitos y fechas límite. Este cronograma sirve como una hoja de ruta para la ejecución del proyecto y ayuda a garantizar que se mantenga en el camino correcto. Hay gente que usa el Project, otros con un Excel es suficiente. Su utilidad es para ver desviaciones, avances, cuellos de botella, esfuerzos, asignación de recursos, etc.
Tiene miga hacer la caseta
🌩️ Gap Analysis (Análisis de Brechas)
Identifica las diferencias entre los procesos de negocio existentes y las capacidades del sistema SAP. Este documento es crucial para determinar las necesidades de personalización o desarrollo adicional.
Sacamos los posibles problemas y damos soluciones alternativas
Fase 3: Realización/Diseño
La Fase 3 es donde se configura y personaliza el sistema SAP según lo definido en el Business Blueprint. Esta fase es crítica para asegurar que SAP funcione de acuerdo con las necesidades y expectativas del negocio. En esta fase:
🧩 Parametrización del sistema
Se realiza la configuración específica de los módulos de SAP para alinear el sistema con los procesos de negocio documentados.
Somos unos máquinas parametrizando
⛏️ Desarrollo ABAP
Involucra cualquier desarrollo de software personalizado necesario para cumplir con los requisitos que SAP no cubre de forma estándar.
En Deloitte ha cambiado mucho el tema de ir en traje
🖇️ Diseño de integraciones
Se detallan las integraciones entre SAP y otros sistemas, asegurando un flujo de datos sin interrupciones.
💼 Documentación técnica
Al finalizar o incluso durante la Parametrización y desarrollo de las funcionalidades para satisfacer los procesos de negocio, se realiza un documento maestro de las funcionalidades SAP implementadas. Puede dividirse en dos, uno de Parametrización y otro de desarrollos. Sea como fuere es un entregable imprescindible. Bajo mi punto de vista se le da poca importancia (nadie lo revisa) a este documento. Cuando es crucial para conocer como esta configurado el sistema.
Yo haciendo la documentación y los manuales
🧙 Documentos de Roles y Perfiles de Usuario
Se definen los roles y perfiles de usuario en SAP, asegurando el acceso adecuado a las funciones y datos del sistema.
Fase 4: Preparación Final
🤸 Pruebas Unitarias
Evalúan las funciones individuales del sistema para garantizar que cada componente funcione según lo previsto.
🤼 Pruebas de Integración
Verifican cómo los diferentes módulos y sistemas integrados funcionan juntos. Ya sea entre SAP y sistemas externos o todo el proceso de inicio a fin en los distintos módulos de SAP.
👥 Pruebas de usuario (UAT)
Las oruebas de Aceptación del Usuario (UAT) se realizan con usuarios finales para asegurar que el sistema cumpla con sus necesidades y expectativas.
🩺 Pruebas de Regresión
Comprueban que las nuevas configuraciones o desarrollos no hayan afectado negativamente las funcionalidades existentes.
📚 Manuales de Usuario
Se elaboran manuales detallados que proporcionan instrucciones sobre cómo utilizar el sistema SAP. Estos son esenciales para la capacitación de los usuarios finales.
👨🏫 Capacitación de Usuarios
Se lleva a cabo la formación de los usuarios finales para asegurar que puedan operar el sistema eficientemente una vez que esté en funcionamiento.
🪂 Plan de Cutover
Se prepara el plan para el traspaso final del sistema antiguo al nuevo sistema SAP, incluyendo la migración de datos y la transición operativa.
Esta fase culmina con la preparación completa del sistema para su implementación y uso en vivo, asegurando que todos los aspectos funcionales y técnicos estén afinados y listos para la operación.
Fase 5: Puesta en Producción y Soporte
La Fase 5 en un proyecto de implementación de SAP es la etapa de «Puesta en Producción y Soporte». En esta fase, es crucial mantener una comunicación efectiva y proporcionar el soporte necesario para garantizar una transición fluida y exitosa al nuevo sistema SAP. Esta fase incluye:
🌅Puesta en Producción (Go-Live)
El sistema SAP se pone en funcionamiento y se utiliza en el entorno real. Esta transición debe ser cuidadosamente planificada y ejecutada.
🚑Soporte Post-Implementación
Proporciona asistencia continua a los usuarios para resolver problemas y adaptarse al nuevo sistema.
⏱️Optimización del Sistema
Incluye el ajuste fino del sistema para mejorar el rendimiento y la eficiencia operativa.
🌋Disaster Recovery Plan (DRP)
Prepara planes de contingencia en caso de problemas graves o desastres para garantizar la continuidad del negocio.
En conclusión
Pero ¡voy a necesitar un par de personas para orquestar todo esto!.
Pues claro, se llaman jefes de proyecto y/o managers y no están (o no deberían) todo el día tomando cafés con otros de su especie. Ahora bien, como con otros perfiles, tienes que ser bueno en esto, metódico, ordenado, analítico, asertivo y, en ocasiones, cortante y estricto..
No obstante, todo el equipo debería tener claras todas las fases, hitos y entregables a realizar. Que luego nos enfadamos cuando nos piden que documentemos.
En todos los campos, pero especialmente en Consultoría TI, y sobretodo con personas competentes que ascienden desde puestos técnicos a puestos de gestión sin formación de liderazgo , se da situación de Microgestión o exceso de control del trabajo de los subordinados.
A mi me ha pasado, pasar de ser «el que hace» a «el que manda hacer» y saber «dejar hacer» es complicado. Como tú nadie lo va a hacer (de mal), y cuando eres el responsable eres tú el que da la cara, aunque no sepas con todo detalle como se han hecho las cosas.
Identificar la Microgestión
La microgestión se manifiesta a través de:
Control Excesivo y Falta de Delegación: Los gestores microgestionan cuando no delegan tareas y toman todas las decisiones, por pequeñas que sean.
Supervisión Constante y Detallada: Supervisan cada detalle del trabajo del equipo, sin permitir autonomía.
Dependencia en Decisiones del Gestor: El equipo se siente incapaz de tomar decisiones sin la aprobación del gestor.
Esto es como tener un hijo y hacérselo todo. No dejar que se forme con autonomía, no dejando que se construya sus capacidades y que se equivoque y aprenda. (Asi tenemos la generación de cristal tan bonita que viene). Luego esos padres se quejan que les dan mucho trabajo.
Causas de la Microgestión
Pero ¿Por qué sucede la Microgestión? Bueno, algo hemos dicho ya, pero vamos a ordenar las causas:
Inseguridad del Gestor: Miedo a perder el control o a que el equipo cometa errores.
Falta de Confianza en el Equipo: Creencia de que el equipo no puede realizar tareas correctamente sin supervisión. Porque tú las sabes hacer, y nunca tuviste que aprender ni equivocarte.
Cultura Organizacional: Algunas empresas promueven un entorno de trabajo donde la microgestión es la norma. Un ejemplo claro es la micrlimputacion y control de tareas diarias. ¿Cómo pongo el tiempo de ir al baño? Estuve 30 minutos hablando de fútbol, ¿Me abres el proyecto de chorradas para imputar por favor?
Efectos de la Microgestión
Y claro, todo esto tiene consecuencias. Consecuencias que los que trabajamos en esto sabemos y vivimos. Incluso nos metemos en callejones sin salida.
Efectos en la Moral y Motivación del Equipo: La microgestión disminuye la moral y desmotiva al equipo. No deja que los profesionales se enfrenten a los retos, se equivoquen, consigan solucionar los retos y consigan exitos.
Disminución de la Productividad: El exceso de control ralentiza los procesos y reduce la eficiencia. Es obvio, mientras el gestor hace el trabajo de otros, ni deja hacer, ni hace el suyo propio.
Aumento del Estrés y Burnout del equipo: La falta de autonomía aumenta el estrés y puede llevar al agotamiento profesional.
Aumento del Estrés y Burnout del gestor: Cuando la microgestión viene impuesta por la empresa. Ya sea por cultura de querer saber que hacen los empleados cada minuto o bien porque no dota el equipo de conocimiento y experiencia suficiente o ambas cosas. En ese caso, el gestor debería gestionar, pero debajo suyo no hay capacidad para desarrollar la la labor y tiene que estar haciendo, sin quererlo, microgestión.
Del síndrome del Burnout ya hablamos en el artículo:
Bueno, como muchas otras cosas lo principal es parar, observar, analizar y sacar conclusiones. Pero muchas veces en la cultura empresarial eso se toma como una pérdida de tiempo (tiempo=dinero). Entre otras cosas se pueden ver las siguientes señales:
Supervisión Constante: Revisiones frecuentes y detalladas de cada tarea. ¿Qué os parece hacer una reunión diaria de 30 minutos para que me contéis qué hacéis?
Poca Delegación: El gestor realiza tareas que deberían ser manejadas por el equipo. Esta bien seguir conectado a los trabajos del día a día, incluso puedes darte tareas como uno más del equipo, pero deja al resto con las suyas de forma autónoma. Mide los resultados, no el proceso.
Baja Moral y Alta Rotación de Personal: Indicadores de un ambiente de trabajo tóxico. Hay empresas que sobre el papel le dan importancia a la rotación, pero en realidad, su cultura dista mucho de generar ambientes laborales sanos. Algunas solo usan ese índice para castigar o menguar los bonus de los responsables.
Estrategias para combatir la Microgestión
Bueno, esto es sentido común, el problema es que, en ocasiones, se entra en la espiral de Microgestión si darse cuenta, y además la cultura de la empresa puede ser proclive a la microgestión. No obstabte, para combatir la microgestión buenas prácticas serian:
Fomentar la Confianza y la Autonomía: Delegar tareas y confiar en las capacidades del equipo. Medir resultados pero no necesariamente el proceso.
Implementar Técnicas de Gestión Efectiva: Utilizar metodologías ágiles y fomentar la comunicación abierta. Las reuniónes de seguimiento son eso, de seguimiento. Proponer reuniones de pares para ayudas técnicas.
Capacitación y Desarrollo de Habilidades de Liderazgo: Formar a los gestores en técnicas de liderazgo que promuevan la autonomía y la responsabilidad.
Dotar al equipo de perfiles con los conocimientos necesarios: Si el equipo no tiene los conocimientos necesarios, el gestor se verá obligado a hacer su trabajo y parte de los subordinados.
En conclusión
La microgestión es un problema significativo en la consultoría IT que puede afectar negativamente tanto al equipo como a los proyectos. Reducir la microgestión a través de la confianza, la delegación y la formación puede mejorar significativamente el ambiente de trabajo y los resultados del equipo. Es crucial que los gestores y las empresas tomen medidas para evitar este estilo de gestión y fomentar un entorno laboral más saludable y productivo.
Jorge Ocampos 