Hace unos días tuve una reunion de asesoramiento con un arquitecto y profesional BIM que me dejó pensando en algo que veo cada vez más seguido entre profesionales con experiencia.
Álvaro trabaja en una empresa constructora vinculada a obra pública.
Es arquitecto y actualmente es la única persona del departamento BIM.
Trabaja con Revit.
Con Civil 3D.
Coordina modelos.
Gestiona incidencias.
Trabaja con BCF.
Ha utilizado Blender.
Ha hecho cursos de Power BI.
Tiene sus propios tableros en Trello.
Documenta algunas lecciones aprendidas.
Es decir: no estamos hablando de alguien que recién empieza con BIM.
Y justamente por eso su problema me pareció interesante.
Porque cuando le pregunté qué estaba buscando, su respuesta no fue:
“Necesito aprender otra herramienta.”
Lo que estaba buscando era algo bastante diferente.
Necesitaba una forma de trabajar.
Álvaro me contó que dentro de la empresa lleva los proyectos prácticamente solo.
Modela.
Coordina.
Organiza.
Controla.
Hace las entregas.
Y cuando aparecen varios proyectos simultáneamente, empieza a hacer malabares entre uno y otro.
Hay momentos en los que puede trabajar relativamente tranquilo.
Pero cuando llega un pico de trabajo, aparece el problema.
Más horas.
Algún fin de semana trabajando.
Entregas que llegan demasiado justas.
Errores que aparecen porque no hubo suficiente tiempo para revisar.
Cambios del cliente que se incorporan sobre la marcha.
Tareas que no estaban contempladas originalmente.
Y una persona intentando absorber todo.
Cuando le pregunté qué ocurría cuando llegaba demasiada carga, la respuesta era bastante lógica:
trabajar más.
Y esto es algo que probablemente muchos profesionales BIM conocen perfectamente.
Mientras el volumen de trabajo es razonable, parece que el sistema funciona.
Pero en realidad no necesariamente hay un sistema.
Hay una persona sosteniendo el proyecto.
Y cuando aumenta la demanda, aparece la diferencia.
El problema mayor aparece cuando querés delegar.
Álvaro ya había intentado externalizar algunas tareas.
Y cuando encontraba empresas o profesionales que ya conocían al cliente, las entregas funcionaban.
Eso le generaba alivio.
Pero había algo interesante detrás de esa situación.
El sistema de trabajo estaba en las empresas que contrataba.
No en él.
Esas personas sabían cómo preparar una determinada entrega porque ya tenían criterios, experiencia, formas de revisar y procesos propios.
Pero Álvaro todavía no había convertido su propia experiencia en una estructura que pudiera transferirle a otra persona.
Y ahí aparece uno de los problemas que más veo en estudios y profesionales que empiezan a crecer.
Piensan:
“Cuando tenga demasiado trabajo, contrato a alguien.”
Pero contratar a alguien no resuelve necesariamente el problema.
Porque entonces aparecen otras preguntas.
¿Qué le delego?
¿Cómo se lo explico?
¿Qué información necesita?
¿Qué decisiones puede tomar sin preguntarme?
¿Qué tengo que revisar?
¿En qué momento tengo que revisar?
¿Cómo sé que lo que está haciendo cumple con los criterios del proyecto?
Y si todas esas respuestas siguen dependiendo de vos, incorporaste una persona al proyecto…
pero vos seguís siendo el cuello de botella.
Delegar no es repartir tareas.
Esta fue una parte muy interesante de la conversación.
Porque Álvaro planteaba algo totalmente real:
cuando incorporás a alguien que todavía no conocés, necesitás revisar lo que hace.
Entonces aparentemente delegar debería liberarte tiempo, pero muchas veces sucede lo contrario.
Ahora tenés que explicar.
Responder preguntas.
Revisar.
Corregir.
Volver a explicar.
Y tomar más decisiones.
Por eso delegar no significa simplemente:
“Vos modelás y yo coordino.”
Para delegar necesitás que exista una estructura previa.
Qué información entra.
Qué resultado tiene que salir.
Qué criterios tiene que cumplir.
Quién es responsable.
Qué decisiones necesitan escalarse.
Qué controles existen.
Qué entregables hay.
Y cuáles son los puntos en los que realmente necesitás intervenir.
La capacidad de delegar no empieza cuando contratás a alguien.
Empieza cuando convertís tu conocimiento en un proceso que otra persona puede ejecutar.
El segundo problema: los cambios del cliente
Durante la conversación apareció otro dolor muy habitual.
Los cambios.
Tenés una planificación.
Tenés una determinada cantidad de trabajo prevista.
Y de repente aparece:
“También necesitamos esto.”
“Hay que modificar aquello.”
“Tenemos que agregar esta información.”
Y muchas veces el cambio entra directamente en producción.
Sin un procedimiento claro para analizar qué implica.
Entonces tenés que insertar una nueva tarea dentro de una planificación que ya estaba funcionando.
Y empiezan los problemas.
Se desplazan otras tareas.
Se consume tiempo que no estaba previsto.
Aparecen horas que nadie está contabilizando.
Y muchas veces terminás haciendo trabajo adicional sin cobrarlo.
Álvaro lo decía muy claramente: algunas veces lo reclamaba y otras veces terminaba absorbiéndolo.
Esto no es solamente un problema comercial.
Es un problema de proceso.
Porque un cambio debería tener una forma definida de ingresar al proyecto.
Hay que poder identificarlo.
Evaluar su impacto.
Determinar qué información modifica.
Qué tareas afecta.
Quién tiene que aprobarlo.
Qué plazo adicional implica.
Y, cuando corresponde, qué costo adicional genera.
Si eso no existe, cada cambio se transforma en una interrupción.
Y cuando acumulás suficientes interrupciones, el proyecto deja de estar gestionado y empieza a estar reaccionando.
En un momento de la conversación le pregunté a Álvaro qué le impedía crear este sistema por su cuenta.
Y su respuesta me pareció especialmente interesante.
Me dijo, básicamente:
“Poder, podría. Lo que me falta es tiempo y me disperso.”
Y creo que esto representa perfectamente a muchos profesionales BIM.
Porque probablemente sea cierto.
Álvaro tiene experiencia.
Tiene conocimiento técnico.
Ha trabajado en proyectos reales.
Ha utilizado distintas herramientas.
Ha documentado algunas cosas.
Seguramente podría sentarse y empezar a construir su propio sistema.
El problema es que después llega el lunes.
Hay una entrega.
Aparece un cambio.
Hay que resolver una incidencia.
Un cliente necesita algo.
Hay que actualizar un modelo.
Y lo importante vuelve a desplazar a lo estructural.
Entonces aparece una paradoja.
No tenés tiempo para crear el sistema porque estás demasiado ocupado trabajando sin sistema.
Y pasan meses.
O años.
Automatizar tampoco resuelve esto.
Álvaro había marcado la automatización como una de sus prioridades.
Y esto también aparece muchísimo actualmente.
Automatización.
Inteligencia artificial.
Nuevas plataformas.
Nuevos softwares.
Pero hay una pregunta anterior:
¿qué proceso querés automatizar?
Porque si hoy no está claro:
qué información entra,
qué decisión se toma,
qué criterio se utiliza,
qué resultado debería salir,
quién controla,
y cómo se mide,
automatizar no necesariamente resuelve el problema.
Puede simplemente hacer más rápido un proceso que ya era desordenado.
Por eso muchas veces digo que BIM acelera el caos si no hay sistema.
Y con la inteligencia artificial ocurre exactamente lo mismo.
Primero necesitás entender cómo debería funcionar la operación.
Después podés decidir qué partes tiene sentido automatizar.
Entonces, ¿por dónde empezar?
No empezaría comprando otra herramienta.
Tampoco empezaría intentando documentar absolutamente todo lo que hacés.
Empezaría por un proyecto real.
Mapeá cómo funciona hoy.
Desde que recibís la información hasta que entregás.
Identificá dónde se pierde tiempo.
Dónde aparecen interrupciones.
Qué decisiones se repiten.
Dónde aparecen errores.
Qué información tenés que buscar constantemente.
Qué cambios generan retrabajo.
Y qué partes ya estás resolviendo siempre de una forma parecida aunque nunca las hayas formalizado.
Después podés empezar a estructurarlo.
Entradas.
Responsables.
Criterios.
Decisiones.
Entregables.
Controles.
Indicadores.
Y recién cuando eso funciona, preguntarte:
¿qué puedo delegar?
Y después:
¿qué puedo automatizar?
El verdadero salto profesional.
Si hoy sentís que cuando aumenta el volumen de proyectos tu única respuesta posible es trabajar más…
si cada vez que delegás necesitás explicar y revisar prácticamente todo…
si tenés procedimientos, checklists, tableros y herramientas, pero siguen funcionando como piezas separadas…
o si llevás meses pensando:
“Cuando tenga un poco más de tiempo voy a ordenar todo esto”…
quizás el problema ya no sea cuánto sabés.
Quizás el problema sea que todo lo que sabés todavía depende de vos para funcionar.
Y esa diferencia es la que determina si podés seguir ejecutando más trabajo…
o empezar realmente a construir capacidad.
