Automatizar procesos BIM: encuentra el atasco real

Cinco automatizaciones urgentes, cinco defensores y una metodología de priorización basada en quién relata mejor su última tarde perdida. Podemos pasar las quejas a Excel para darles apariencia científica, pero el cuello de botella seguirá sin identificar. Me han encargado introducir un criterio algo menos expresivo. Vamos a seguir una entrega, localizar dónde espera y elegir una mejora que podamos comprobar antes de discutir qué lenguaje la hará parecer más moderna.

En una entrega hipotética entre disciplinas, escoger la primera automatización obliga a mirar más allá de la tarea que molesta a cada persona. ¿Cuál retrasa a los demás, cuánto cuesta preparar sus datos y qué mejora podríamos comprobar? Esas preguntas permiten comparar las cinco candidatas antes de elegir lenguaje. Me interesa que la elegida libere trabajo del conjunto; desarrollar impecablemente la que mejor se defendió en la reunión puede dejarnos un script excelente y la entrega igual de atascada.

El trabajo que más molesta no siempre es el que más retrasa

Imagina un equipo que comparte modelos cada semana. Antes de coordinar, alguien comprueba qué revisiones han llegado, confirma su estado, prepara la federación y devuelve observaciones. Entretanto, otras personas dedican tiempo a nombrar vistas o colocar planos. Todas esas tareas tienen un coste, pero no todas condicionan el momento en que otra disciplina puede avanzar. El cuello de botella depende de la capacidad y de las dependencias del recorrido, no de cuántas veces te haga suspirar una operación.

Supongamos, solo para razonar, que exportar consume veinte minutos de máquina y que confirmar si un modelo está listo implica esperar hasta el día siguiente. Automatizar por completo la exportación no elimina esa espera. Podría aportar valor si libera atención o permite ejecutar fuera de horario, pero no deberías venderlo como solución al retraso que ocurre antes de empezar. La mejora local y la mejora de la entrega son cosas relacionadas que no conviene sumar como si fueran la misma.

Dibuja el recorrido de un paquete y marca dónde se queda esperando. Necesitas distinguir llegada, inicio de revisión, devolución, nueva recepción y aceptación. Junto a esos momentos, registra qué impide avanzar: falta una versión, no está claro el requisito, el archivo no abre o nadie tiene asignada la decisión. Si solo mides el tiempo que una persona está delante del ordenador, parte del problema quedará fuera de la observación con una elegancia estadística considerable.

Observa también qué ocurre después de tu mejora candidata. Una validación más rápida puede trasladar el atasco a quien debe interpretar los resultados. Si produces cien incidencias en un minuto pero nadie distingue cuáles requieren intervención, has incrementado el volumen de trabajo pendiente. El resultado interesante sería que el responsable reciba antes un conjunto relevante y pueda resolverlo, no que el contador de avisos alcance una cifra con más dígitos.

En el ejemplo, investigaríamos si el atasco está en recibir información identificada o en comprobar su contenido. La respuesta podría cambiar entre proyectos e incluso entre fases. No hace falta convertir la oficina en un laboratorio de tiempos durante seis meses, pero sí observar varios ciclos comparables y hablar con quien recibe el resultado. El compañero que sufre el siguiente paso suele detectar limitaciones que la demostración del automatizador había omitido con gran entusiasmo.

Compara candidatas por valor, claridad y capacidad de comprobarlas

Para decidir entre las cinco ideas empezaría por describir su resultado esperado en una frase. Renombrar vistas podría evitar inconsistencias en un conjunto conocido; crear planos, preparar una entrega repetible; exportar, liberar una tarea de salida; revisar parámetros, detectar incumplimientos antes de compartir; generar incidencias, devolver hallazgos con contexto. Si una propuesta solo puede describirse como «ahorrar mucho tiempo», todavía necesitas averiguar en qué operación y para quién.

Después contrasta frecuencia e impacto. Una tarea frecuente pero irrelevante para los destinatarios puede ahorrar clics sin mejorar la entrega. Un error poco frecuente puede merecer un control si contamina todo el paquete y resulta caro de detectar más tarde. No asignes puntuaciones aparentando una precisión que no tienes: explica el razonamiento y registra qué datos faltan. Cinco columnas con notas del uno al diez no vuelven objetiva una decisión tomada a ojo; únicamente la alinean mejor.

La estabilidad del criterio pesa tanto como la repetición. Renombrar vistas puede ser sencillo si existe una convención clara y puedes detectar colisiones. Crear planos puede resultar mucho más variable si cada proyecto decide de otra manera qué vistas deben aparecer y cómo se distribuyen. En ese caso quizá tenga sentido automatizar una ayuda parcial, como señalar planos incompletos o preparar una propuesta revisable, antes de fabricar una composición que alguien tendrá que comprobar entera.

Valora también la calidad de las entradas y la posibilidad de verificar la salida. Una lista de equipos con identificadores consistentes facilita aplicar reglas y devolver resultados localizables. Una colección de capturas sin modelo ni versión obliga a reconstruir el contexto antes de hacer nada útil. La automatización podría ayudarte a recoger ese contexto, pero no deberías estimarla como si el dato ya estuviese disponible. El presupuesto rara vez agradece los requisitos que aparecen vestidos de sorpresa.

Por último, incorpora el daño de un fallo y la forma de recuperarse. Un informe de lectura incorrecto puede inducir decisiones equivocadas, aunque no escriba en el modelo. Una modificación masiva añade además el riesgo de cambiar elementos fuera de alcance. No se trata de prohibir las operaciones útiles, sino de exigir una comprobación proporcionada: muestra, vista previa, autorización y verificación del efecto cuando corresponda. Un proceso fácil de repetir y difícil de revisar no es necesariamente un buen primer piloto.

Diseña un piloto que pueda refutar tu propia idea

Supongamos que la observación apunta al tramo de recepción y devolución. El piloto podría aceptar una revisión identificada, aplicar un pequeño conjunto de comprobaciones y producir un informe que permita actuar. Para delimitarlo, fija qué disciplina entra, qué uso tiene la entrega, qué modelos esperas y qué requisitos vas a revisar. Deja fuera de esa primera prueba la promesa de corregir automáticamente todos los problemas. Cuanto más estrecha sea la pregunta, más fácil será saber si la herramienta la responde.

Escribe los casos antes de programar. Si quieres comprobar códigos de activos, necesitas un ejemplo correcto, otro sin código, otro con un valor fuera de las opciones admitidas y otro que no deba evaluarse porque está fuera del ámbito. Añade una entrada que no se pueda leer. El resultado esperado de esta última es informar de que la revisión no ha podido completarse, no demostrar una ausencia milagrosa de defectos. Ahí empieza a verse si el diseño contempla el trabajo real o únicamente su versión fotogénica.

Define también qué significaría que tu hipótesis era equivocada. Tal vez el informe detecte los datos ausentes, pero las devoluciones continúen porque nadie conoce el valor que debe introducir. Quizá la regla sea correcta, pero el equipo pierda más tiempo preparando la entrada que revisando manualmente. O puede que la demora esté en una autorización que no cambia con el control. Esos resultados permiten replantear el piloto antes de ampliar una herramienta que mejora el tramo equivocado.

Durante la prueba conserva la revisión manual de una muestra y registra discrepancias. Si el humano y el sistema no coinciden, investiga el motivo: regla ambigua, alcance incorrecto, error del código o criterio que todavía no estaba expresado. Ninguna de las partes merece tener razón por defecto. Yo agradezco la confianza en las máquinas, pero preferiría que llegase acompañada de un caso de prueba.

Una vez resuelto ese pequeño recorrido, puedes conectarlo con estados y responsables. Si quieres profundizar en cómo se encadenan controles, excepciones y publicación, el artículo sobre automatización BIM y flujos trazables desarrolla esa parte. Aquí la decisión previa es más incómoda: demostrar que ese recorrido merece automatizarse antes de pedirle a alguien que lo mantenga durante los próximos años.

Elige la tecnología después de conocer sus obligaciones

El piloto ya te dice qué tiene que leer la solución, dónde se ejecuta y qué debe devolver. Con eso puedes comparar herramientas de forma útil. Si el trabajo está dentro del modelo y el equipo necesita visualizar una secuencia de operaciones, un prototipo en Dynamo puede ser razonable. Si necesitas procesar archivos y organizar reglas o informes, un programa en Python puede encajar. Si debes distribuir una herramienta integrada y controlar su interacción con Revit, un complemento sobre su API puede justificar más desarrollo.

Estas opciones se solapan. Dynamo puede incorporar código y Python puede ejecutarse en distintos entornos, cada uno con sus límites. No elijas un lenguaje suponiendo que accederá por sí mismo a cualquier modelo abierto o que garantizará compatibilidad con todas las versiones. El contexto de ejecución, los permisos y las dependencias forman parte de la herramienta. Son menos vistosos que un grafo, pero se niegan obstinadamente a desaparecer porque no los menciones en la propuesta.

La IA merece el mismo examen. Si el problema consiste en comprobar si un campo pertenece a una lista, una regla explícita ofrece un resultado más fácil de reproducir que una interpretación generativa. Si necesitas agrupar comentarios ambiguos o preparar un resumen, una ayuda de IA puede tener sentido siempre que permita volver a la evidencia. Una propuesta no debería convertirse en una aceptación técnica solo porque esté redactada con una seguridad que el modelo no se ha ganado.

Asigna un propietario del proceso y alguien capaz de mantener la solución. El primero decide qué significa el requisito; el segundo adapta la implementación y sus pruebas cuando cambia el entorno. Pueden coincidir en una persona, pero son responsabilidades distintas. Incluye cómo se corrige una regla, dónde se conserva su versión y qué hará el equipo cuando falle una dependencia. Una herramienta que nadie sabe reparar deja de ahorrar tiempo en un momento bastante inoportuno.

Defiende una candidata con tres datos: qué se repite, quién utiliza la salida y cómo comprobarías que ha mejorado el recorrido. Si renombrar vistas resulta la mejor inversión, adelante; no había obligación de descubrir que necesitabais una plataforma propia. Priorizar también consiste en dejar una buena idea esperando. La lista de deseos puede conservar su entusiasmo sin dirigir el presupuesto.