Las operaciones de una consultora conectan demanda, personas, delivery y caja. Una venta se convierte en proyecto; el proyecto requiere skills y capacidad; las personas registran horas y gastos; finanzas convierte actividad aprobada en datos económicos. Cuando CRM, ATS, proyectos y timesheets viven separados, cada traspaso pierde contexto.
Lo que se pierde en cada traspaso no es solo tiempo. Es la respuesta a preguntas que la dirección necesita a diario y que, con sistemas fragmentados, requieren dos días y tres personas: cuánto margen deja realmente el proyecto que acaba de cerrarse, quién estará disponible dentro de seis semanas, qué parte del trabajo entregado el mes pasado sigue sin facturar y qué oportunidades del pipeline no podríamos entregar aunque las ganásemos.
El coste de la fragmentación crece de forma no lineal con el tamaño. Con diez consultores, una persona bien organizada mantiene la coherencia entre sistemas con esfuerzo razonable. Con cuarenta, esa misma coherencia exige una rutina semanal completa, y con cien deja de ser posible: aparecen versiones distintas del mismo número según quién prepare el informe, y la discusión se desplaza de qué hacer a qué dato es correcto.
Empieza por el modelo operativo
Mapea cuatro recorridos: lead-to-project, recruiting-to-staffing, delivery-to-timesheet y project-to-margin. Para cada paso define evento, owner, datos, aprobación y sistema propietario. Una oportunidad firmada debe crear proyecto con cliente, scope, fechas, tarifa y manager sin reinserción.
Define variantes. T&M, fixed price, retainer y managed service necesitan controles distintos. T&M depende de horas y rate card; fixed price necesita avance, esfuerzo restante y hitos; retainer distingue capacidad incluida y extra-scope.
Estos son los controles mínimos por tipo de contrato, y conviene tenerlos configurados antes del primer proyecto real en el sistema.
| Tipo de contrato | Riesgo principal | Control que lo detecta a tiempo |
|---|---|---|
| Time & Materials | Horas no aprobadas o fuera de tarifa | Aprobación semanal y alerta de tarifa caducada |
| Precio cerrado | Esfuerzo restante mayor que el previsto | Estimate-to-complete revisado cada quincena |
| Retainer | Consumo por encima de la capacidad incluida | Contador de capacidad usada frente a contratada |
| Managed service | Erosión silenciosa del margen | Coste por unidad de servicio con serie histórica |
El error habitual es aplicar los controles del T&M a todo. En un proyecto de precio cerrado, las horas registradas dicen lo que se ha gastado pero no lo que falta, y el margen solo se conoce cuando alguien estima el trabajo restante con honestidad.
Conecta CRM, recruiting y capacidad
El pipeline no es solo forecast de ingresos. Alimenta capacidad con probabilidad, inicio, duración, rol y skills. Resource management y recruiting comparan demanda ponderada, backlog, disponibilidad, bench y salidas.
Si falta una skill, decide contratar, partner, freelance, formar o retrasar. Registrar supuestos mejora el forecast. La plataforma de operaciones de HICE conecta oportunidades, personas y proyectos.
Para que el pipeline alimente la capacidad hacen falta cuatro datos que el CRM tradicional no pide: roles necesarios, fecha de inicio, duración y dedicación semanal por rol. Sin ellos, una oportunidad ponderada es un número de ingresos que no se puede planificar. Con ellos, el responsable de recursos ve la demanda probable con semanas de antelación y puede actuar antes de que el problema sea urgente.
Diseña una identidad por persona
Una persona puede entrar como candidato, convertirse en empleado o freelance, ser presentada, asignada y registrar horas. No debe recrearse. Perfil, skills, seniority, disponibilidad, cost rate, documentos e historial tienen permisos distintos y una identidad.
Define ownership: consultor confirma skills y horas; manager valida seniority y delivery; HR gestiona contrato; finanzas protege costes. Evita scores opacos de performance y utiliza evidencias y resultados con contexto.
La identidad única es también una cuestión de permisos, no solo de comodidad. La misma persona tiene datos que deben ver perfiles distintos: sus horas las ve su manager, su coste lo ve finanzas, su documentación contractual la ve RRHH y su perfil de skills lo ven quienes hacen staffing. Un modelo con una sola identidad y permisos por atributo resuelve esto; un modelo con cuatro copias de la persona en cuatro sistemas termina, casi siempre, en que alguien exporta una hoja con todo junto para poder trabajar.
Integra el timesheet en delivery
El timesheet señala esfuerzo, avance, scope creep, utilización y billing. Simplifica entrada con proyectos predefinidos, chat o interfaz, recordatorios selectivos y aprobación por excepción. Pide la granularidad que produce una decisión o una obligación.
Cada hora se vincula a persona, cliente, proyecto, actividad, periodo y aprobación. El control de horas debe mostrar faltas y anomalías antes del cierre, no cuando finanzas ya prepara facturación.
La granularidad excesiva es el motivo más común de que un sistema de horas fracase. Pedir imputación en bloques de quince minutos con cinco niveles de categoría produce datos peores, no mejores: la gente rellena al final de la semana de memoria y el resultado es una ficción precisa. La regla es pedir el detalle que produce una decisión o una obligación contractual, y ni un campo más.
El otro punto de fricción es la aprobación. Si el manager debe revisar línea a línea, no lo hará y aprobará en bloque el último día. La aprobación por excepción, que resalta solo lo anómalo (horas fuera de asignación, exceso sobre lo previsto, imputaciones a proyectos cerrados, tarifas sin actualizar), convierte una tarea de media hora en una de tres minutos y, paradójicamente, mejora el control.
Controla margen y riesgo pronto
El margen combina ingreso contractual, coste de personas, gastos y estimate-to-complete. Para T&M controla bill rate, cost rate, utilización y horas; en fixed price, valor, esfuerzo y resto; en retainer, consumo y extra-scope.
Crea alertas por proyectos sin horas, aprobaciones vencidas, margen bajo, tarifas antiguas, fin de asignación y forecast incoherente. El cockpit semanal muestra excepciones con owner y próxima acción.
Define KPI y cadencia
Semanalmente revisa pipeline, backlog, capacidad, bench, timesheets y riesgos. Mensualmente añade utilización, margen, datos de facturación y forecast. Trimestralmente analiza skills, pricing, clientes y pérdidas.
Publica definiciones para capacidad, hora facturable, cost rate y margen. Si las unidades usan reglas distintas, documenta y consolida explícitamente.
Un glosario operativo de una página evita la mayoría de las discusiones estériles en los comités. Debe decir, entre otras cosas, si la utilización se calcula sobre horas laborables o sobre horas disponibles, si el cost rate incluye cargas sociales y estructura, si el margen es bruto o después de gastos directos, y qué se considera una hora facturable cuando el trabajo se descuenta comercialmente. Publicarlo y no cambiarlo a mitad de ejercicio vale más que cualquier dashboard adicional.
Implementa ciclos y retira Excel
Selecciona una unidad y lleva una oportunidad hasta proyecto, staffing, horas y cierre. Migra clientes, personas, proyectos activos, tarifas y saldos. Ejecuta dos cierres paralelos y concilia.
Retira hojas cuando datos, integraciones, informes y owners estén aceptados. Un Excel temporal durante seis meses es otra fuente de verdad. HICE permite empezar gratis, conectar procesos prioritarios y ampliar sin cambiar plataforma.
En qué orden conviene unificar
No hace falta unificarlo todo a la vez, y hacerlo suele ser la forma más rápida de agotar la paciencia del equipo. El orden que menos riesgo genera empieza por el par proyecto-horas, porque es donde se produce el dato económico y donde la mejora se nota en el primer cierre. Después se incorpora la capacidad y el staffing, que dependen de tener horas y asignaciones fiables. En tercer lugar entra el pipeline, con los campos de demanda que permiten planificar antes de firmar. Y solo al final se aborda la parte de recruiting y candidatos, que es la que más datos históricos arrastra.
Ese orden tiene una lógica sencilla: cada etapa deja instalado el dato que la siguiente necesita. Empezar por el CRM, que es lo más habitual porque es lo más visible para la dirección comercial, deja el proyecto sin economía fiable durante meses y hace que el sistema se perciba como una carga administrativa antes de haber dado nada a cambio.
Cómo saber si la unificación está funcionando
Tres preguntas bastan para evaluarlo a los tres meses. La primera: ¿cuánto se tarda desde el cierre de mes hasta emitir la factura, y ha bajado respecto a la baseline? La segunda: ¿puede un manager ver el margen actualizado de sus proyectos sin pedírselo a nadie? La tercera: ¿queda alguna hoja de cálculo que alguien consulte para tomar una decisión real?
Si la respuesta a la tercera sigue siendo afirmativa después de dos cierres completos, merece la pena averiguar qué contiene esa hoja. Casi siempre guarda un dato que el sistema no modela o un informe que no sabe producir, y es información mucho más valiosa que cualquier encuesta de satisfacción sobre la herramienta.
Plan de acción para 30 días
Nombra un owner para el sistema operativo de la consultora y captura una baseline antes de cambiar herramientas o workflows. La primera semana mapea traspasos, decisiones y datos; la segunda limpia una muestra real y configura el recorrido mínimo; la tercera ejecuta el piloto con varias funciones; la cuarta concilia resultados, corrige excepciones y decide qué trackers retirar.
Documenta objetivo, responsable, medida inicial, evidencia de aceptación y fecha de revisión. Configurar software no es éxito. El éxito llega cuando el equipo completa un ciclo real, dirección confía en el resultado y el trabajo manual puede apagarse. Si HICE está en la shortlist, crea un entorno gratuito y prueba el mismo escenario sin cambiar todo el proceso de golpe.