En una consultora el dinero se hace a nivel de un solo proyecto, no del informe anual. Un socio suele saber por intuición qué proyectos sostienen el resultado y cuáles se lo comen, solo que ese conocimiento vive en la cabeza de la gente y en hojas de cálculo, no en una vista coherente. Por eso la analítica para consultoras no empieza por los gráficos, sino por una pregunta: ¿sabemos de verdad cuánto cuesta y cuánto gana realmente un proyecto concreto?
Por nuestra experiencia, lo difícil no es dibujar un cuadro de mando, sino llevar los datos de proyectos, personas y contratos a un estado en el que las cifras cuadren. Aquí no tenemos un caso de éxito listo que enseñar, pero sí tenemos lo que más cuenta en un proyecto así: ingenieros de datos, arquitectos de BI y especialistas en ML que incorporamos al equipo del cliente para que esa base se construya y se mantenga.
¿Por qué una consultora necesita su propia analítica de proyectos?
Porque el modelo de negocio de la consultoría es sensible a varias variables a la vez: la tarifa, la utilización de los consultores, la entrega frente al presupuesto de horas y el reconocimiento de ingresos en el tiempo. Basta con que una se descuadre para que el margen del proyecto desaparezca, a menudo antes de que alguien lo note en el cierre mensual.
Los sistemas estándar no muestran esto como un todo. El ERP conoce las facturas, la herramienta de horas conoce las horas, el CRM conoce el pipeline y RR. HH. conoce los costes de personal, pero ninguno une todo eso en una imagen de la rentabilidad de un solo proyecto. Una capa analítica dedicada es donde esos mundos se encuentran, y donde un socio director deja de guiarse por intuición.
¿Cómo diseñar un almacén de datos para proyectos de consultoría?
La base es un modelo de datos que describa cómo funciona realmente la firma, no cómo se ve en la teoría. Solemos construirlo alrededor de unas pocas entidades clave:
- el proyecto como unidad central, con su tipo de contrato (precio cerrado, time & material, retainer),
- el consultor y su rol, con coste, tarifa de venta y disponibilidad,
- el parte de horas, atado a un proyecto y a una tarea,
- el contrato y el presupuesto, con ingreso y coste previstos,
- el cliente y su sector, para el análisis de cartera y el benchmarking.
Encima de esto ponemos un modelo dimensional clásico (hechos y dimensiones), porque permite calcular las mismas métricas en distintos cortes, desde un consultor hasta toda una línea de negocio, sin reescribir la lógica para cada pregunta nueva.
¿Cómo construir cuadros de mando de margen y utilización?
Este es el corazón de la solución, porque aquí miran a diario el COO y los socios. Los cuadros de mando de margen y utilización deberían responder a las preguntas operativas más rápido de lo que costaría montarlas a mano:
- margen por proyecto y por cliente, dividido entre previsto y realizado,
- utilización por consultor, equipo y práctica, separando horas facturables y no facturables,
- consumo del presupuesto de horas y coste frente al calendario (similar a una métrica burn/EAC),
- tarifa efectiva frente a la tarifa de catálogo,
- reconocimiento de ingresos y trabajo en curso (WIP) en proyectos facturados por fases.
La clave es que esas métricas se calculen una sola vez, en un solo sitio, con una única definición. De lo contrario, dos departamentos llevan a la reunión dos márgenes distintos y la discusión pasa a ser de quién es el Excel verdadero.
¿Cómo crear bibliotecas de benchmarks y estimaciones?
El benchmarking es el momento en que los datos del pasado empiezan a rendir en las propuestas futuras. Del histórico de proyectos construimos bibliotecas de benchmarks y estimaciones, es decir, conocimiento estructurado sobre cuánto duran y cuánto cuestan de verdad los tipos de trabajo repetibles.
En la práctica eso significa parametrizar los proyectos por tipo, sector, tamaño y composición del equipo, y después calcular las distribuciones del esfuerzo real frente a las estimaciones originales. Ventas deja de cotizar «a ojo» y un responsable nuevo obtiene un punto de referencia en vez de una página en blanco. Es además la forma más honesta de nombrar los proyectos que sistemáticamente no cierran bien, y de entender por qué.
¿Cómo prever el pipeline y la capacidad?
Una consultora vende tiempo de personas, así que la previsión de pipeline y capacidad es en esencia cruzar dos curvas: la demanda del pipeline y la oferta de los calendarios del equipo. Si las miras por separado, siempre acabas con sobrecalentamiento o con banquillo.
Por eso combinamos el pipeline ponderado del CRM con la asignación prevista y la disponibilidad de los consultores, para sacar a la luz los futuros huecos y excedentes de capacidad con semanas o meses de antelación. Esa vista convierte las conversaciones de dirección de reactivas en planificadoras: en vez de apagar un fuego por falta de gente el trimestre que viene, puedes empezar a reclutar antes, mover un equipo o frenar ventas a propósito en un área sobrecargada.
¿Cómo mantener la calidad y la coherencia de los datos de origen?
El cuadro de mando más fino pierde contra un parte de horas mal imputado, y por eso tratamos la calidad y coherencia de los datos de origen como una parte propia del proyecto, no como un añadido. Los problemas típicos son previsibles:
- horas registradas tarde o en el proyecto equivocado,
- definiciones distintas del mismo concepto (qué cuenta como facturable) entre departamentos,
- un desajuste entre el contrato en el CRM y el alcance real del trabajo,
- huecos en los datos de coste de consultores y subcontratistas.
Por eso integramos validaciones y pruebas de datos en los procesos de carga, alertas para los huecos y un glosario de métricas claro. No se trata de tener datos perfectos desde el primer día, sino de que los errores sean visibles y se corrijan en el origen antes de llegar a la pantalla de un socio.
¿Cuándo merece la pena recurrir a previsiones con ML?
Cuando las reglas simples y los promedios dejan de bastar y ya hay suficiente histórico para que los patrones se vean. Las previsiones con ML no sustituyen a los cuadros de mando; añaden una capa de predicción donde una persona no puede ponderar todas las dependencias.
En consultoría esto suele tener sentido para predecir la probabilidad de cierre de una oportunidad del pipeline, predecir la desviación de presupuesto de un proyecto a partir de señales tempranas y prever la utilización del equipo en los próximos periodos. Es una competencia real que aportamos, aunque lo decimos claro: el ML solo tiene sentido sobre datos limpios, así que suele ser una etapa posterior, no la primera.
¿Qué competencias aportamos a un proyecto así?
Formamos el equipo alrededor del trabajo concreto, no «por si acaso». En proyectos de analítica para firmas de servicios profesionales suelen ser:
- un ingeniero de datos que construye los pipelines y el almacén (ELT/ETL, modelado),
- un arquitecto/analista de BI responsable del modelo de métricas y de la capa de cuadros de mando,
- un analytics engineer que vela por las definiciones y las transformaciones,
- un especialista en ML cuando entran las previsiones,
- un especialista de DevOps / plataforma de datos para el despliegue, la seguridad y el mantenimiento.
Esta configuración permite que un equipo asuma de verdad la propiedad de la capa de datos, y no que entregue un informe y desaparezca.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que aporta competencias de datos, BI y ML al proyecto, incluso cuando es tu equipo el que marca la dirección:
- reforzamos el equipo con especialistas concretos cuyas competencias verificamos antes de empezar,
- diseñamos el modelo de datos de la consultora antes de que exista el primer gráfico,
- unimos las fuentes (ERP, registro de horas, CRM, RR. HH.) en un almacén mantenible,
- añadimos la capa de ML solo donde los datos están listos para ella, sin promesas que no podamos sostener.
No fingimos tener un despliegue terminado que enseñar en este área; aportamos a las personas y el enfoque que hacen que ese despliegue ocurra en tu firma y se mantenga.
¿Por dónde empezar con la analítica de proyectos de consultoría?
Empieza por una decisión que quieras tomar mejor, por ejemplo «¿aceptamos este proyecto con este equipo?», y por la pregunta de qué datos requiere. Eso define el alcance de la primera iteración del almacén, el conjunto de métricas y los roles que necesitas. Un cuadro de mando de margen fiable vale más que diez en los que nadie cree. Las diferencias entre modelos de colaboración las describimos en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir analítica y benchmarking para los proyectos de tu consultora? Hablemos - ajustaremos un equipo de datos/BI/ML y una arquitectura a tu firma.
Construye con nosotros la analítica y el benchmarking de tus proyectos