Cada viernes a las 4 de la tarde, doce personas se conectan a una llamada para revisar el estado financiero de los proyectos. El director de operaciones lee una hoja de cálculo. Los gerentes de proyecto van comentando, uno por uno, qué se facturó, qué se gastó, qué se atrasó. La llamada dura noventa minutos. La conclusión es siempre la misma: dos proyectos vienen apretados de margen y nadie sabe exactamente cuánto.
Si esa escena te suena familiar, no estás solo. Es el ritual financiero estándar en empresas de servicios profesionales de la región. Y es exactamente la razón por la que no tienes finanzas de proyecto en tiempo real.
La llamada del viernes no es una buena práctica de gestión. Es el parche que tu empresa armó para sobrevivir a la ausencia de un sistema. El problema no es que la llamada sea larga o aburrida. El problema es que existe.
La llamada existe porque la información financiera del proyecto no vive en ningún sistema accesible. Vive en la cabeza del PM, en correos de proveedores, en facturas escaneadas que alguien guardó en una carpeta de Drive, y en un Excel maestro que solo una persona sabe actualizar.
Cuando la dirección quiere saber el margen real de un proyecto, no tiene a dónde ir a verlo. Tiene que pedirle a alguien que lo arme. Esa persona necesita tiempo, contexto y disponibilidad. La llamada del viernes es la forma de coordinar todo eso en un solo bloque de la semana.
El verdadero problema no es de personas. Tu PM no es desorganizado. Tu director financiero no es lento. Tu CFO no es paranoico. Todos están haciendo lo que pueden con la infraestructura que tienen.
La infraestructura es el problema. Cuando los costos de un proyecto viven en facturas de proveedores que llegan por correo, los ingresos viven en el ERP, las horas viven en una hoja de tiempos paralela, y el alcance vive en una propuesta firmada hace cuatro meses, no hay forma de saber el margen real sin que alguien junte todo manualmente.
Lo que se pierde no es solo tiempo de reunión. Se pierde velocidad de decisión. Para cuando descubres que un proyecto está perdiendo plata, ya pasaron tres semanas desde que empezó a perderla. Renegociar alcance con el cliente en ese punto ya no es viable.
Y se pierde algo más sutil: la dirección termina tomando decisiones financieras con datos de hace dos viernes. En proyectos de tres a seis meses, eso es un porcentaje brutal del ciclo de vida operando a ciegas.
Cuando una empresa de servicios reconoce este problema, casi siempre intenta lo mismo. Primero, alguien construye un Excel maestro mejor. Más pestañas, más fórmulas, más colores. Funciona dos meses, hasta que alguien rompe una referencia o el archivo se corrompe.
Después contratan un project controller o un analista financiero que dedique su tiempo a consolidar la información. El resultado es predecible: ahora hay una persona que se vuelve indispensable, que tiene todo el contexto en su cabeza, y que cuando se va de vacaciones la empresa queda ciega. Esto lo hemos visto en consultoras en Bogotá, en firmas de arquitectura en Santiago y en agencias en Buenos Aires.
El Excel maestro no falla por ser Excel. Falla porque la información que necesita vive fuera de él. Alguien tiene que bajar reportes del ERP, pegar datos del CRM, pedirle al PM que actualice las horas, conseguir las facturas de proveedores que llegaron esa semana.
Cada uno de esos pasos depende de una persona haciendo algo manualmente. Tres pasos manuales son suficientes para que el sistema entero se atrase. Por eso siempre hay un viernes en el que el Excel no está listo y la llamada se llena de "déjame revisar y te confirmo el lunes".
Un project controller convierte el caos en un trabajo de tiempo completo. No elimina el caos. La empresa termina pagándole a alguien por hacer lo que un sistema bien implementado debería hacer solo.
Peor aún: ese controller se vuelve el cuello de botella. Si necesitas saber el margen de un proyecto un martes a las 11 de la mañana, tienes que preguntarle a él. Y si él está ocupado, esperas. La llamada del viernes no desaparece, solo cambia de operador.
La reframe es esta: el margen de un proyecto no es un reporte que se construye. Es una propiedad que se calcula automáticamente sobre datos que ya existen en el sistema.
Para que eso funcione, cada movimiento de dinero asociado al proyecto tiene que vivir como un registro estructurado, no como un archivo adjunto en un correo. Cada factura de proveedor es un registro. Cada factura emitida al cliente es un registro. Cada hora cargada es un registro. Todos están asociados al proyecto correspondiente.
Con esa estructura, una propiedad de tipo rollup en el proyecto suma automáticamente los ingresos, suma los costos, y calcula el margen. En tiempo real. Sin que nadie tenga que armar nada. Cuando el CFO abre el proyecto en el CRM, ve el margen actual del momento exacto en que lo abrió.
El PM no tiene que reportar el estado financiero. El estado financiero se reporta solo, porque las facturas ya están cargadas en el sistema como parte del flujo operativo normal. El PM hace su trabajo y los datos quedan estructurados como subproducto.
La dirección no tiene que esperar al viernes. Puede entrar al portafolio de proyectos cualquier día a cualquier hora y ver exactamente cuál está apretado de margen, cuál está sobrevendido, cuál tiene facturas pendientes por cobrar.
Acá está el detalle técnico que separa una implementación buena de una mediocre: el CRM y el ERP tienen que compartir un identificador único por proyecto. Un ID consistente en ambos sistemas. Eso es todo lo que se necesita para que las facturas emitidas en el ERP se asocien automáticamente al proyecto correcto en el CRM.
No importa si usas SAP, Oracle, Dynamics u Odoo. Lo que importa es que el ID del proyecto sea el mismo en ambos lados. Con ese único dato consistente, el margen en tiempo real deja de ser un proyecto de TI y se vuelve una integración trivial.
Si quieres saber qué tan profundo es el problema en tu empresa, revisa esta lista. Si reconoces tres o más, no tienes finanzas de proyecto en tiempo real:
Cada uno de estos puntos es una grieta por donde se escapa margen. No de a poco: en cantidades que justifican rediseñar la operación entera.
Cuando los datos viven en el sistema y el margen se calcula solo, la conversación cambia. La dirección deja de revisar el pasado y empieza a tomar decisiones sobre el presente. Si un proyecto entra en zona de riesgo en la semana 3, lo ves en la semana 3. Tienes tiempo de renegociar, ajustar alcance, redirigir recursos.
El director financiero deja de ser el que reporta y empieza a ser el que asesora. Los gerentes de proyecto recuperan los 90 minutos del viernes. Y la empresa entera empieza a operar con una capa de visibilidad que antes simplemente no existía. Esto no es una ganancia menor: es la diferencia entre escalar con caos o escalar con control.
Si quieres ver exactamente cómo se ve un sistema donde las facturas, los costos y los ingresos viven asociados al proyecto y el margen aparece solo, acá está el modelo completo que implementamos para empresas que venden proyectos. No es una teoría — es la arquitectura que ya está corriendo en consultoras, agencias y firmas de servicios profesionales que decidieron dejar de operar a ciegas hasta el viernes siguiente.